Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. read cgit's README.selinux 2. perform command suggested: semanage fcontext -a -t httpd_git_content_t "/srv/git(/.*)" Actual results: ValueError: Type httpd_git_content_t is invalid, must be a file or device type Expected results: Execute without error Additional info: 1. This fcontext is parameterised in the rpm build but is wrong for rhel7 2. It probably should be git_sys_content_t as that exists. 3. It's probably wrong for Fedora too; README.linux there has git_content_t but /var/lib/git is (I think!) actually git_sys_content_t
Thanks for the report. I agree that 'git_sys_content_t' is a very good guess for RHEL6, RHEL7 and also Fedora. I originally thought (bug 1036123) that looking at /var/www/git makes some sense, but it doesn't. I checked Fedora Rawhide and RHEL7 selinux-policy sources, and there's something like: optional_policy(` git_read_generic_sys_content_files(httpd_t) `) Which operates on git_sys_content_t. Further checking: | RHEL5> matchpathcon /var/www/git /var/lib/git | /var/www/git system_u:object_r:httpd_sys_content_t | /var/lib/git system_u:object_r:var_lib_t var_lib_t is just a bad default. So we still need to use httpd_sys_content_t on RHEL5. | RHEL6> matchpathcon /var/www/git /var/lib/git | /var/www/git system_u:object_r:httpd_git_content_t:s0 | /var/lib/git system_u:object_r:git_sys_content_t:s0 httpd_sys_content_t works here, too, together with git_sys_content_t. | RHEL7> matchpathcon /var/www/git /var/lib/git | /var/www/git system_u:object_r:git_content_t:s0 | /var/lib/git system_u:object_r:git_sys_content_t:s0 | F25> matchpathcon /var/www/git /var/lib/git | /var/www/git system_u:object_r:git_content_t:s0 | /var/lib/git system_u:object_r:git_sys_content_t:s0 git_sys_content_t works here. Fixed as 3ede86ef29356c3872d74c6db76a3c78db4fd234 commit in epel7 and f27 (rawhide).
cgit-1.1-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-473d31b05f
Hi Pavel, Thanks for the prompt and complete response. I have a secondary bug (or at least I think I do) on rhel7. I have never been able to make cgit work no matter what context I make various files. I know is that works with selinux off and doesn't work with it on. The actual error -- as given by audit2allow is # === httpd_t === allow httpd_t httpd_sys_script_exec_t:file execute_no_trans; But I suspect that that is a symptom. I know I should raise another bug report but could you please check whether cgit works out of the box for you on rhel7? It works OK on Fedora 25.
Matthew, it looks your /var/www/cgi-bin/cgit has httpd_sys_script_exec_t but it should have git_script_exec_t. Can you confirm (and fix)?
cgit-1.1-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-473d31b05f
Pavel, yes it had a different context. That was me attempting to fix. It failed with git_script_exec_t as well. I found the problem underlying both failures. The fs was mounted nosuid. This prevents the selinux transition. Simply re-mounting suid fixed the problem. It is also possible to make /var/www/cgi-bin a bind mount and make the bind mount suid while the rest of /var is nosuid. The remounts require a restart of httpd. Feel free to close this issue. Thanks, Matt PS it would be nice if nosuid was mentioned more prominently in selinux docs; perhaps the FAQ section on resolving problems https://docs.fedoraproject.org/en-US/Fedora/13/html/SELinux_FAQ/index.html#faq-div-resolving-problems
(In reply to Matthew Hannigan from comment #6) > The fs was mounted nosuid. This prevents the selinux transition. > Simply re-mounting suid fixed the problem. > It is also possible to make /var/www/cgi-bin a bind mount and make the bind > mount suid while the rest of /var is nosuid. Hmm. I'm curious how you get to this resolution; I'm able to reproduce the issue though I don't see anything in audit.log. So for me it would be really hard to debug. > The remounts require a restart of httpd. > > Feel free to close this issue. It should close itself once the update is pushed. > PS it would be nice if nosuid was mentioned more prominently in selinux > docs; perhaps the FAQ section on resolving problems > https://docs.fedoraproject.org/en-US/Fedora/13/html/SELinux_FAQ/index. > html#faq-div-resolving-problems It is IMO fair to submit such request to selinux guys.
> I'm curious how you get to this resolution Sheer dogged determination and elimination of the impossible :-) Comparing a system that worked against a system that didn't. I knew that our sysadmins did extra hardening on our machines but they said they did not tweak or add any selinux policies themselves. So I had to look elsewhere but somewhere closely related. Actually, I remember a very similar problem I had a couple of years ago. Possibly also with a cgi-bin. Nagios perhaps? So, I half-remembered that incident too.
cgit-1.1-4.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a00c707deb
cgit-1.1-5.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c089298a4c
cgit-1.1-5.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c089298a4c
cgit-1.1-5.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.