Cool stuff!
Just finished work (yes, some people work until 1am) while peeking in here every now and then during work but this is just what I like when I can finally relax and enjoy a cold beer
Although my experience in this stems mostly from Linux I obviously did look up some of the things on FreeBSD as well. However; keep this in mind as I can't claim to be 100% sure about everything I share here.
fonz said:
[*]By default only root may use at. Does allowing mortal users to use at raise any significant security issues?
It does raise some security issues and I think they can be significant. The reason I feel that security is involved is because of this:
Code:
chihiro:/home/peter $ ls -l `which at` `which crontab`
-r-sr-xr-x 4 root wheel 29656 Dec 4 2012 /usr/bin/at
-r-sr-xr-x 1 root wheel 32840 Dec 4 2012 /usr/bin/crontab
As you can see
at (as well as
crontab) have the
setuid bit set, that makes them both a security issue to me, even though it might be minimal (executables which have the
setuid bit set always do that to me).
Yet the other reason why I feel this way is because
at actually seems to be fully controlled by
crontab. Check this out:
Code:
chihiro:/home/peter $ grep atrun /etc/crontab
*/5 * * * * root /usr/libexec/atrun
This behaviour is also confirmed in the
at(1) manual page as well as the
atrun(8) manual page. Because there's always a "5 minute window" this doesn't make
at the best tool to carefully time something. But I also wonder if that time overhead couldn't also decrease the risks: you can basically tell
crontab to execute something the very next (same?) minute whereas this isn't so obvious with
at.
Even so, there's something else to worry about...
fonz said:
[*]As far as I can tell, it appears impossible (without hacking the source that is) to let at execute jobs but not send e-mails with the results/output. Is that right?
Ok, so this is one of those issues I'm not 100% sure about but I'm going to share my idea anyway. I think you're right, but I also think you might be overlooking another obvious problem: generating output also means assuming that the job at hand actually generated output in the first place. As you know it's pretty easy to send that to
/dev/null.
Which is in my opinion one of the reasons
at is less secure then
cron. When a job is executed through
crontab you see something like this:
Code:
Jun 9 13:35:00 smtp2 /usr/sbin/cron[79844]: (root) CMD (/usr/libexec/atrun)
([I]root ran atrun[/I])
Jun 9 15:00:00 smtp2 /usr/sbin/cron[82377]: (root) CMD (newsyslog)
([I]root ran newsyslog[/I])
Jun 9 22:40:00 smtp2 /usr/sbin/cron[32571]: (root) CMD (/usr/local/etc/webmin/virtualmin-awstats/awstats.pl synthfan.info)
([I]root updated stats for my synthesizer hobby site[/I])
Although I only picked out jobs executed by
root the exact same thing applies to jobs scheduled by a common user: you see
exactly what has been scheduled and what is being executed.
So what do you get to see when
atrun does something? You see in the
/var/log/cron that it was executed with
root privileges, but what more can you tell about it? Especially when there's no output generated by the scheduled command?
I think that's what makes
at more of a risk factor in comparison to
crontab.