allbery@ncoast.UUCP (Brandon Allbery) (10/23/86)
Expires: Quoted from <1040@ho95e.UUCP> ["Re: Which commands (in /bin & /usr/bin) must have set user ID (for root)"], by wcs@ho95e.UUCP (#Bill.Stewart)... +--------------- | In article <735@hropus.UUCP> jrw@hropus.UUCP (Jim Webb) writes: | >-rwsr-xr-x 1 root sys 47197 Oct 20 1985 at | >-rwsr-xr-x 1 root sys 25093 Nov 5 1983 crontab | >at needs to talk to cron in a very specific manner. | I would expect you could write a good cron without setuid, since /etc/cron runs | as root? Likewise "at", since it's the other side of cron? +--------------- Both "crontab" and "at" work in the same way: (1) write a file in a protected directory (to keep non-superusers from doing fun things like changing other users' at files or setting up crontabs/at jobs when they're listed in {cron,at}.deny), and (2) write something to /usr/spool/cron/FIFO, which is protected for the same reasons as above. (I wish I'd thought of that way of doing things; it makes sense. 20/20 hindsight, eh?) +--------------- | What irks me more, though, is that the "lp" commands all run setuid-lp | setgid-bin; this means that in a directory which lp can't access ( e.g. 700), | lp foo | fails, though | lp <foo | is ok. +--------------- It *might* be possible to run "lp" setgid only -- but that might not help you. (Although it would take strange circumstances to do that.) But "lp" revolves around a few special files in /usr/spool/lp and ordinary users shouldn't be allowed to muck with them; even if they know what they're doing, mucking with /usr/spool/lp/outputq while lpsched is running is a good way to trash the print queue. ++Brandon -- ---------------- /--/ Brandon S. Allbery UUCP: decvax!cwruecmp! / / /|\/ Tridelta Industries, Inc. ncoast!tdi2!brandon ---- -------- /-++ 7350 Corporate Blvd. PHONE: +1 216 974 9210 / / /---, ---- Mentor, Ohio 44060 SYSOP: UNaXcess/ncoast / / / / / / -- HOME -- (216) 781-6201 24 hrs. / / / / / / 6615 Center St. Apt. A1-105 ARPA: ncoast!allbery% ---- -----~ ---- Mentor, Ohio 44060-4101 case.CSNET@relay.cs.net