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

@bagasme commented on GitHub (Feb 6, 2020):

Disabling selinux for now?

@bagasme commented on GitHub (Feb 6, 2020): Disabling selinux for now?

GiteaMirror commented

@rmbleeker commented on GitHub (Feb 10, 2020):

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.

@rmbleeker commented on GitHub (Feb 10, 2020): 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](../blob/master/contrib/systemd/gitea.service). 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.

GiteaMirror commented

@stale[bot] commented on GitHub (Apr 11, 2020):

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[bot] commented on GitHub (Apr 11, 2020): 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.

GiteaMirror commented

@stale[bot] commented on GitHub (Apr 25, 2020):

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

@stale[bot] commented on GitHub (Apr 25, 2020): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror commented

@vwbusguy commented on GitHub (Jul 20, 2021):

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

@vwbusguy commented on GitHub (Jul 20, 2021): I would really appreciate this. It's the worst game of whack a mole on CentOS 8.

GiteaMirror commented

@zeripath commented on GitHub (Jul 20, 2021):

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.

@zeripath commented on GitHub (Jul 20, 2021): 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.

GiteaMirror commented

@vwbusguy commented on GitHub (Jul 20, 2021):

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.

@vwbusguy commented on GitHub (Jul 20, 2021): 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.

GiteaMirror commented

@rmbleeker commented on GitHub (Jul 21, 2021):

@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.

@rmbleeker commented on GitHub (Jul 21, 2021): @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.

GiteaMirror commented

@vwbusguy commented on GitHub (Jul 23, 2021):

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.

@vwbusguy commented on GitHub (Jul 23, 2021): 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.

GiteaMirror commented

@vwbusguy commented on GitHub (Sep 4, 2021):

I think I've figured out an SELinux policy that works, though it could be more granular. I suspect much of my problem may have been that I'm running the data directory in an alternative path where others are likely using /var/lib, etc.

But these two things fixed most (maybe all?) of the issues for me:

The executable binary should be labeled as "bin_t" (Ie: chcon -v -t bin_t gitea-1.15.2-linux-amd64)
The gitea data location should be labelled var_lib_t (In my case: chcon -Rv -t var_lib_t /local/gitea/)

@vwbusguy commented on GitHub (Sep 4, 2021): I *think* I've figured out an SELinux policy that works, though it could be more granular. I suspect much of my problem may have been that I'm running the data directory in an alternative path where others are likely using /var/lib, etc. But these two things fixed most (maybe all?) of the issues for me: - The executable binary should be labeled as "bin_t" (Ie: `chcon -v -t bin_t gitea-1.15.2-linux-amd64`) - The gitea data location should be labelled var_lib_t (In my case: `chcon -Rv -t var_lib_t /local/gitea/`)

GiteaMirror commented

@sebeaumont commented on GitHub (Jan 30, 2025):

@vwbusguy Thank you indeed for that. Did it make it into any documentation?

@sebeaumont commented on GitHub (Jan 30, 2025): @vwbusguy Thank you indeed for that. Did it make it into any documentation?

GiteaMirror commented

@lunny commented on GitHub (Jan 31, 2025):

Since the documentation has been relocated to https://gitea.com/gitea/docs , this issue should be moved there for further discussion or resolution. The file https://gitea.com/gitea/docs/src/branch/main/docs/installation/from-binary.md should be updated.

@lunny commented on GitHub (Jan 31, 2025): Since the documentation has been relocated to https://gitea.com/gitea/docs , this issue should be moved there for further discussion or resolution. The file https://gitea.com/gitea/docs/src/branch/main/docs/installation/from-binary.md should be updated.

GiteaMirror commented