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.
I got a reply from bugzilla's Max Kanat-Alexander on their mailing list:
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: