home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9584 < prev    next >
Encoding:
Text File  |  1992-09-01  |  1.4 KB  |  32 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!gatech!bloom-beacon!bloom-picayune.mit.edu!daemon
  3. From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  4. Subject: Re: clearing SUID bit on writes
  5. Message-ID: <1992Sep1.170221.17317@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: Tue, 1 Sep 1992 17:02:21 GMT
  10. Lines: 20
  11.  
  12.    From: vesseur@fwi.uva.nl (Joep JJ Vesseur)
  13.    Date: Tue, 1 Sep 1992 09:11:47 GMT
  14.  
  15.    when appending to a file with S_ISUID bit set, linux keeps the
  16.    'bit up', while i think it's desirable that whenever anyone appends 
  17.    to such a file, the bit gets cleared. the same holds for S_ISGID
  18.    bits.  i don't know whether the behaviour of setuid files is defined
  19.    somewhere (at least i can't find it in 'the design and implementation
  20.    of the 4.3bsd unix operating system', i don't have docs on sysV); 
  21.    all i know is that SunOs clears the bit.
  22.  
  23. When System V does is whenever you write to a setuid file (not just when
  24. you append to it), it clears the setuid and setgid bits.  This prevents
  25. a security hole if you have a setuid program which is group or world
  26. writeable.  I don't think anything would break if we added this behavior
  27. to Linux.  On the other hand, there's a much simpler way of avoiding the
  28. security hole, which is to simply don't create group or world writeable
  29. setuid files.
  30.  
  31.                             - Ted
  32.