home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9127 < prev    next >
Encoding:
Text File  |  1992-08-26  |  1.4 KB  |  40 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!snorkelwacker.mit.edu!bloom-picayune.mit.edu!daemon
  3. From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  4. Subject: Re: Suid/sgid
  5. Message-ID: <1992Aug26.162407.6349@athena.mit.edu>
  6. Sender: daemon@athena.mit.edu (Mr Background)
  7. Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  8. Organization: The Internet
  9. Date: Wed, 26 Aug 1992 16:24:07 GMT
  10. Lines: 28
  11.  
  12.    From: rafal@utstat.uucp (Rafal Kustra (summer student))
  13.    Date: Tue, 25 Aug 1992 23:09:07 GMT
  14.  
  15.    Either I don't understand the concept of suid/sgid
  16.    (**very** possible) or there is something wrong.
  17.  
  18.    Say root creates a script like follows:
  19.        cat $*
  20.    and sets it suid.
  21.  
  22.    <description of how the setuid shell script apparently didn't have
  23.     root privs omitted>
  24.  
  25. This should probably be added to the FAQ.
  26.  
  27. Setuid shell scripts are a bad, bad, bad, bad, bad thing.  They
  28. represent a gigantic security hole for your system.  There is either a
  29. race condition you can exploit to break root, or (depending on how dumb
  30. your shell is), you can sometimes just confuse it enough by using a
  31. symlink to giving you a root shell.  
  32.  
  33. So on most modern Un*x systems (Linux included), setuid shell scripts
  34. are specifically disabled by the kernel.  If you must have a shell
  35. script which needs to run as root, write a small C program that execs
  36. the shell script, and make sure that no one can spoof the C program into
  37. running some other program besides your shell script.
  38.  
  39.                             - Ted
  40.