Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!clyde!cbatt!ihnp4!inuxc!pur-ee!j.cc.purdue.edu!k.cc.purdue.edu!aij From: aij@k.cc.purdue.edu (Ray Moody) Newsgroups: net.unix-wizards Subject: Re: Which commands (in /bin & /usr/bin) must have set user ID (for root) Message-ID: <1565@k.cc.purdue.edu> Date: Sun, 26-Oct-86 22:48:44 EST Article-I.D.: k.1565 Posted: Sun Oct 26 22:48:44 1986 Date-Received: Mon, 27-Oct-86 23:23:13 EST References: <115@tijc02.UUCP> <735@hropus.UUCP> <1040@ho95e.UUCP> <743@hropus.UUCP> Reply-To: aij@k.cc.purdue.edu.UUCP (Ray Moody) Organization: Purdue University Computing Center Lines: 34 Summary: No need to take away write permission for setuid programs. >> What surprised me about the list Jim replied with was that most of the >> commands >> were -rws......! Why should a setuid command *ever* be writeable? - it's just >> *inviting* attempts to find a bug and convince the command to write >> over itself. > >First off, root can overwrite any file regardless of perms, yes/no? Second, >ever see "error: text busy" ? You cannot remove or write over a file that >is running somewhere on the system (or, to be picky, has the sticky bit set >and has been run) Anyway, if a setuid program overwrites itself, it is no longer setuid! It says in the manual page for write (2): If the real user is not the super-user, then _w_r_i_t_e clears the set-user-id bit on a file. This prevents penetration of system security by a user who "captures" a writable set- user-id file owned by the super-user. >> 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 >then make lp suid root :-) There shouldn't be any smiley face here. This is a perfectly reasonable suggestion. Just MAKE SURE IT CALLES ACCESS (2)! Out lpr program runs setuid. array array Ray Moody array ihnp4!pur-ee!pucc-s!aij array