[DOC] Add some hints to enable gitea on selinux/Ubuntu/Fedora

[guillep2k]

Users that attempt to install Gitea from binary on Fedora/Ubuntu/etc. may encounter several problems due to selinux. I'm not an expert on that, but I think we should add a couple of hints to the docs around this scenario.

Notes that might be useful:

• setcap cap_net_bind_service=+ep /path/to/binary/gitea will allow the exact version of gitea's executable to bind to privileged ports; this permits Gitea to bind directly to 443 without running as root. Upgrading Gitea (i.e. replacing the executable) will remove this capability and force the admin to run the command again.

• There's a number of considerations for running the service from systemd if selinux is active; if we can't provide a full recipe for enabling Gitea, we may leave some pointers about these limitations.

(I might do this myself if I ever get time to investigate this setup).

[bagasme]

Disabling selinux for now?

[rmbleeker]

I've having no issues running Gitea under its own user account on a host with selinux set to enforcing. To bind to ports 80 and 443 set CapabilityBoundingSet=CAP_NET_BIND_SERVICE and AmbientCapabilities=CAP_NET_BIND_SERVICE in the systemd unit file, they are commented out in the example unit file.
Other than that I'm running from a directory in /opt and haven't even looked at the selinux security contexts on the files in that directory.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.

[vwbusguy]

I would really appreciate this. It's the worst game of whack a mole on CentOS 8.

[zeripath]

The problem is someone needs to play that game of whackamole and write the documentation for us...

So if you have just done this - please consider documenting what you needed to do.

[vwbusguy]

I would if setroubleshoot gave meaningful things and not touch /.autorelabel and ausearch -c 'gitea' --raw | audit2allow -M my-gitea && semodule -X 300 -i my-gitea.pp

I simply don't have the time to sort through all of that, sadly, especially if it's complicated enough that setroubleshoot isn't going to even give more meaningful hints.

I think that running restorecon on the binary and recursively on the gitea data path may have solved part of it.

[rmbleeker]

@vwbusguy can you perhaps elaborate a little more on what parts of Gitea are not working for you due to selinux? As I've stated before in this issue, I'm running Gitea on a RHEL7 host with selinux set to enforcing and have not run into any issues.

I have an Ansible role that I use for the installation and configuration of Gitea but it's also based around RHEL7 so I'm not sure if that would be of any help to you.

[vwbusguy]

It seems the biggest issue is proper labelling for the data directory/binary for file system writes. I doubt the SELInux policy would be any different between EL7 and EL8 for Gitea.