This question about Documentation: Task filed
Root rights for mailnotify and genwebnotify considered harmful?
By copying and pasting
lines such as the one from Question148
or the one in KennethLavrsen
's private documentation (http://www.lavrsen.dk/foswiki/bin/view/Kenneth/TWikiOnRedHat
) I was tempted into running both
as root. In the end, I had the following line in my crontab:
05 3,11,15 * * * root ( cd /usr/local/share/foswiki/bin && ../tools/genwebnotify && ../tools/mailnotify -q )
This made Foswiki behave strangely on the first day of each month. Foswiki seems to have some internal log rotating mechanism which causes logYYYYMM.txt and warnYYYYMM.txt to be created once for each month. Now, if no Foswiki action (view, configure, whatever...) was performed before 3:05 a.m. on the frist day of any given month, then the first run of
was the first thing that wrote a log message, causing the log file to be created. Since, however,
was run as root, the log file was created wih root permissions as well. This, in turn, froze Foswiki since no other component was able to write any logs subsequently.
It took me quite a while to find out that first of all,
was causing this trouble and moreover,
does not (seem to) require root privileges (and neither does
At first I thought at least
needed root in order to set the sender of the notification mails appropriately. It turned out, it doesn't, at least in our setup where mails are sent using
. One might still need root privileges if the local
binary is used instead, but I haven't tried.
In the end, the only question remaining is: did I get anything wrong? I don't think there is a bug to be reported because
can't tell whether it should drop privileges it was given by accident. So this entry is meant merely as a support for those who shot themselves in the foot just like me...
- 07 Sep 2009
Already tried to add a
chown www:www ..../logs/log*.txt
to your scripts?
- 09 Oct 2009
Nope -- would have been too
easy, wouldn't it?
In fact, I had your solution in mind as a last resort. But I wanted to dig a little deeper (great way to procrastinate a few other things...) and share my findings with the community. If you can think of a better way to do so, I'd love to know.
My actual problem was solved simply by not running
as root. Maybe I didn't state that clearly enough. Still I wonder if there are any scenarios in which either of these two scripts does
need root privileges. If so, my solution wouldn't work. Otherwise I think that it's closer to the root cause of the problem than cleaning up afterwards using
Feel free to mark my non-question "closed unanswered" if you think this problem is too exotic.
- 23 Oct 2009
One other cleanup item, since we're "documenting", is that when MailerContrib
is run as root, it creates work items as root in foswiki/working/work_areas/MailerContrib
If you then remove root from the crontab as above, and if those aren't chown'd back from root, I find that you get the same notifications over and over as MailerContrib
can't edit it's working files.'
- 24 Oct 2009
Good catch, Uwe. Please feel free to raise tasks against the MailerContrib
to clarify this in the documentation. these cron jobs should always be run as the apache user, and never run as root. Even if it wasn't for this permissions problem, running them as root is a potential hole for a hacker.
- 05 Nov 2009
There you go: Foswiki:Tasks.Item2474
However, there might be some more of those scripts out there. If they are to be run from cron jobs and write their logs to
, they're probably prone to this kind of behaviour, too.
- 07 Dec 2009
BTW: Changed the Subject to
"Using an extension"
"Documentation". Seems more appropriate to me...
- 07 Dec 2009