Bugs in the "at" command - FIX DOES WORK!!!

bob at SU-SHASTA.ARPA bob at SU-SHASTA.ARPA
Wed Jul 25 08:26:29 AEST 1984


The fix that I posted yesterday to the net to eliminate the security hole
in having "at" on System III & System V does indeed work!  Matt is wrong
in claiming that it does not work!

The security hole was that once a user had used "at" to create a spool file
in the /usr/spool/at directory they could chown it away (like, to root).
The heart of my fix is the command 'chmod 700 /usr/spool/at'.  Matt failed
to realize that this prevents users from then chowning their spool file,
/usr/spool/at/*, because they won't able to access /usr/spool/at anymore!

The "at" command and the "atrun" daemon can still access /usr/spool/at because
they run as root.  I'm reposting the fix:
-------------------------------------------------------------------------------
The fix for making "at" secure under System III & System V is to do this:
	chmod 700 /usr/spool/at
	chown root /usr/spool/at
	chmod 4755 /usr/bin/at
If your cron doesn't run as root also do:
	chmod 4755 /usr/lib/atrun
	chown root /usr/lib/atrun

The several versions of "at" that I've seen all chown the spool file to the
real UID so it's safe to make it set-uid and also prevent one from reading
files that the real UID isn't allowed to.

Note that no source changes or re-compilation is required.

Bob Toxen
Silicon Graphics
ucbvax!Shasta!olympus!bob



More information about the Comp.unix.wizards mailing list