Xref: utzoo comp.unix.questions:14716 comp.unix.wizards:17146 Path: utzoo!mnetor!motto!ecijmm!ecicrl!eci386!clewis From: clewis@eci386.UUCP Newsgroups: comp.unix.questions,comp.unix.wizards Subject: Re: at files and permissions Message-ID: <1989Jul6.204710.5550@eci386.uucp> Date: 6 Jul 89 20:47:10 GMT References: <1894@cbnewsh.ATT.COM> <669@lzaz.ATT.COM> <8072@bsu-cs.bsu.edu> Reply-To: clewis@eci386.UUCP (Chris Lewis) Distribution: na Organization: R. H. Lathwell Associates: Elegant Communications, Inc. Lines: 32 In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >In article <669@lzaz.ATT.COM> hutch@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