4

To enable bug graphs in Bugzilla you need to run collectstats.pl as a nightly cron-job. The manual has a section on setting this up - add a cron job

5 0 * * * cd <your-bugzilla-directory> ; ./collectstats.pl

However it doesn't say which user to run it as. To be paranoid, we run this as the apache user not root since that's what Bugzilla itself effectively runs as. However for a few versions now Bugzilla's checksetup.pl strips out write permissions to files beneath data/ when run, even permissions for the apache group which is set as our $webservicegroup in localconfig. The collectstats job then tries to write to data/mining/ as the apache user and fails because its permissions were removed.

This means every time we modify Bugzilla and run checksetup we then have to restore apache group and write permissions in the data directory, e.g.

cd data
chgrp -R apache *
chmod -R g+w bugzilla-update.xml mailer.testfile mining/ template/ webdot/ \
             duplicates/

So what are we doing wrong? Are we actually expected to be running the collectstats cron job as root? I guess I run checksetup as root so I trust that not to be malicious, but collectstats runs with user supplied input so that doesn't feel right.

Thanks. Couldn't find anything obvious on Google. Running on CentOS 5.4, httpd 2.2.3, Bugzilla 3.4.x and 3.6.x from CVS checkouts in case that matters.

1 Answer 1

4

I got a reply from bugzilla's Max Kanat-Alexander on their mailing list:

[run it] As root would be best.

I'm not sure I really buy that for safety reasons as above - it's processing user-supplied data.

Another idea I got off-list was to not run checksetup.pl as root so it couldn't chown/chgrp permissions away. I'll probably go with that or stick to my old workflow (checksetup as root then run my fix permissions script).

Follow-up: MKA replied to the second idea too:

However, that would lead to insecure permissions where the web server has the ability to write to things that it should not have the ability to write to.

You could also create a "bugzilla" user, make that "bugzilla" user a member of the Apache group, and run both checksetup.pl and collectstats.pl as the "bugzilla" user. That leads to greater complications in setting up permissions for other things (for example, jobqueue.pl would then also have to run as "bugzilla", email_in.pl would have to run as "bugzilla", etc.) but if you are seriously concerned about the security of running as root, it's another option (and much better than running checksetup.pl as apache).

1
  • Very surprised the first thing to come to their mind was to run it as root! Feb 26, 2011 at 19:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .