Created attachment 732074 [details] selinux logs Description of problem: My Fedora 18 server was happily serving Bugzilla 4.2.4 pages with SELinux set to Enforcing with policy selinux-policy-targeted-3.11.1-85.fc18.noarch. After a Bugzilla 4.2.5 update and SELinux update to selinux-policy-targeted-3.11.1-86.fc18.noarch, I can no longer bring up my Bugzilla instance. I am met with 3 different SELinux AVCs. I ran "restorecon -Rv /usr/share/bugzilla" but this did not resolve the problem. Version-Release number of selected component (if applicable): selinux-policy-3.11.1-86.fc18.noarch selinux-policy-targeted-3.11.1-86.fc18.noarch bugzilla-4.2.5-1.fc18.noarch How reproducible: Always Steps to Reproduce: 1. Install Bugzilla 2. Attempt to view index.cgi or query.cgi in a web browser 3. Actual results: Bugzilla has suffered an internal error. Please save this page and send it to [email removed] with details of what you were doing at the time this message appeared. URL: http://example.com/query.cgi Template->process() failed twice. First error: file error - cache failed to write search-advanced.html.tmpl: Error in tempfile() using /usr/share/bugzilla/data/template/usr/share/bugzilla/template/en/default/search/XXXXXXXXXX: Could not create temp file /usr/share/bugzilla/data/template/usr/share/bugzilla/template/en/default/search/SPNRC0tc05: Permission denied at /usr/lib64/perl5/vendor_perl/Template/Document.pm line 303. Second error: file error - cache failed to write code-error.html.tmpl: Error in tempfile() using /usr/share/bugzilla/data/template/usr/share/bugzilla/template/en/default/global/XXXXXXXXXX: Could not create temp file /usr/share/bugzilla/data/template/usr/share/bugzilla/template/en/default/global/ck6xRdLxjE: Permission denied at /usr/lib64/perl5/vendor_perl/Template/Document.pm line 303. Expected results: Bugzilla web page Additional info: Logs are attached.
What is /usr/share/bugz?
(In reply to comment #1) > What is /usr/share/bugz? The SELinux tool is truncating "/usr/share/bugzilla/...". I do not have a "/usr/share/bugz" directory nor is it declared anywhere in Bugzilla.
Ok currently we label everything under this directory as httpd_bugzilla_script_exec_t, What files should be labeled as cgi entry points of httpd_bugzilla_script_exec_t and which should be writable by the apache process? Is it a good idea to have writable content in /usr?
I am guessing the /usr/share/bugzilla/data is not a standard directory. # semanage fcontext -a -t httpd_bugzilla_content_rw_t '/usr/share/bugzilla/data(/.*)?' # restorecon -R -v /usr/share/bugzilla/data If this is a standard directory then I need to update the policy.
Now that I thought about it, Bugzilla should be writing to /var/lib/bugzilla and not /usr/share/bugzilla. I believe Bugzilla is broken and it wasn't the 4.2.5 update. Downgrading to 4.2.4 results in the same problem. The Bugzilla maintainer should take a look.
We should indeed be writing under /var and not /usr . Actually, I'm pretty sure we fixed this a while and dropped the patch when it was accepted upstream. I'll investigate.
*** Bug 958121 has been marked as a duplicate of this bug. ***
This is still a bug with 4.2.6. Any update on the patch?
(In reply to Michael Cronenworth from comment #8) > > This is still a bug with 4.2.6. Any update on the patch? It turns out the two aren't related (the patch was on graph generation and this is something else). Here, Template Toolkit is trying to compile a template and can't because it doesn't have write access to /usr/share/bugzilla/data/template/ . I've looked in the TT documentation and couldn't easily figure out how to change it the location to something else. I'll have more time in the coming week to figure where this is coming from.
I have run into this as well on F18, kernel 3.9.10-200.fc18.x86_64, with bugzilla-4.2.6-1.fc18.noarch. Once I noticed rpm was claiming /usr/share/bugzilla/data was not owned by any package, I deleted the directory and replaced it with a symlink to /var/lib/bugzilla/data. After that, everything is happy. So, there's a fairly painless workaround. But it would be nice to have a clean fix. Any further news?
bugzilla-4.2.7-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/bugzilla-4.2.7-1.fc18
bugzilla-4.2.7-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/bugzilla-4.2.7-1.fc19
bugzilla-4.2.7-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/bugzilla-4.2.7-1.fc20
Package bugzilla-4.2.7-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing bugzilla-4.2.7-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-19402/bugzilla-4.2.7-1.fc20 then log in and leave karma (feedback).
Created attachment 814837 [details] bugzilla constants patch The $datadir variable is being overridden at $datadir = "$libpath/$datadir"; so any calls result in "/var/lib/bugzilla//usr/share/bugzilla/data" being used as the template_cache path. I have attached a patch that fixes not only this bug but a partial fix for the PROJECT variable bug. The PROJECT bug was partly upstream and partly your patch that changes Constants.pm (missing $ in localconfig). The PROJECT variable bug has one last fix required in that bz_locations() is being memoize'd in a BEGIN block and the function never reads the PROJECT environment variable. I'm not an expert Perl programmer so I'll discuss this with upstream for a fix. Feel free to pick only a few things out of my patch in the mean time.
Created attachment 814839 [details] updated bugzilla constants Sorry, I noticed I uploaded an old patch. This new patch is all that is required.
(In reply to Michael Cronenworth from comment #15) > Created attachment 814837 [details] > bugzilla constants patch > > The $datadir variable is being overridden at $datadir = "$libpath/$datadir"; > so any calls result in "/var/lib/bugzilla//usr/share/bugzilla/data" being > used as the template_cache path. As inelegant as this is, it should fix the problem (unless selinux is preventing bugzilla from writing in /var/lib/bugzilla). Are you still getting an error message saying you can't write in /usr/share/bugzilla/ ? > I have attached a patch that fixes not only this bug but a partial fix for > the PROJECT variable bug. The PROJECT bug was partly upstream and partly > your patch that changes Constants.pm (missing $ in localconfig). Thanks. I'll release an update today or tomorrow to fix this. > The PROJECT variable bug has one last fix required in that bz_locations() is > being memoize'd in a BEGIN block and the function never reads the PROJECT > environment variable. I'm not an expert Perl programmer so I'll discuss this > with upstream for a fix. Feel free to pick only a few things out of my patch > in the mean time. I'll keep an eye on the upstream bug (#843457 in bmo).
(In reply to Emmanuel Seyman from comment #17) > As inelegant as this is, it should fix the problem (unless selinux is > preventing bugzilla from writing in /var/lib/bugzilla). Are you still > getting an error message saying you can't write in /usr/share/bugzilla/ ? There are no more SELinux denials, but I would prefer a proper fix rather than a quick fix.
bugzilla-4.2.7-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
bugzilla-4.2.7-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
bugzilla-4.2.7-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.