Path: utzoo!attcan!uunet!image.soe.clarkson.edu!news From: klehr@sun.soe.clarkson.edu (Thomas J. Klehr) Newsgroups: comp.os.minix Subject: Re: Problems with at and atrun in V1.5.10 Message-ID: Date: 31 May 90 13:24:25 GMT References: <90150.164149SA44@LIVERPOOL.AC.UK> Sender: news@sun.soe.clarkson.edu Distribution: comp.os.minix Organization: Clarkson University, Potsdam NY Lines: 30 In-reply-to: SA44@LIVERPOOL.AC.UK's message of 30 May 90 15:41:49 GMT In article <90150.164149SA44@LIVERPOOL.AC.UK> SA44@LIVERPOOL.AC.UK (Kevin Maguire) writes: >At and atrun only need be setgid at. Setting them as uid root is a potential >security hole :-( Create a new group at, and make /usr/spool/at and >/usr/spool/at/old (or whatever this is called) writable by group at. But, the "atrun" program uses setuid() and setgid() to make the process run as if the person who made it (via at) had done it himself. Likewise, "at" must chown() the new file in order to save the user's uid and gid. If "at" was setgid() only, then the file created would have "at"'s gid, and when it ran from "atrun" (if atrun is setuid root), it might be able to do something it isn't supposed to do, like "rm -rf /usr/spool/at". If it doen't matter who owns the process atrun forks, then using a new group will work fine. If, however, at.c and atrun.c are both written correctly (and I'm not saying that they're not now), then setuid root should not create any problems. If you look at the diffs I posted for at.c, you'll see that it unlinks any file that it can't chown correctly. If it didn't, the file would still be owned by root, and when atrun came along, it would run it as if root created it. I would like to remind you that, according to V1.5.10's fixbin.sh, that "at" was designed to be setuid root. And since "atrun" uses setuid() and setgid(), it should only be used by root (I have it run from cron, which is owned by root). Tom -- Thomas J. Klehr