Bug 949130

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.