at files and permissions

[clewis at eci386.UUCP]

In article <8072 at bsu-cs.bsu.edu> dhesi at bsu-cs.bsu.edu (Rahul Dhesi) writes:
>In article <669 at lzaz.ATT.COM> hutch at lzaz.ATT.COM (R.HUTCHISON) writes:
>>If I wanted to be sneaky (and if "at" wasn't very smart), I could submit 
>>a "nasty" at job, go to the spool directory, and change the file's owner 
>>id to a target login and "at" would do the nasty to that login.  

>The above problem does not occur in BSD, because BSD allows only root
>to change file ownership.

	1) it isn't a problem in SV, 'cause at won't run it.  Like he said.
	   Because, even though you can chown a file away from yourself,
	   at will insist that the setuid bits are set before believing
	   the ownership of the file.  And, when you chown, the setuid
	   bits are turned *off*.  And you can't turn 'em on once you've
	   given the file away.
	2) BSD *does* allow you to give files away.  It turns off the
	   setuid bits too.  If it doesn't work on your system, obviously
	   someone disabled it for accounting reasons.

>When you discuss a security problem that is specific to System V,
>please be sure to say so clearly, else you may confuse naive users.

It wasn't necessary for him to say so, because it *isn't* a security problem.

"at" needs setuid root permissions so that it can write in the cron/at 
spool directories.  In SVR3, there's no specific utility to run the "at" jobs,
they seem to be simply shovelled into cron.
-- 
Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc.
UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis
Phone: (416)-595-5425