home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / linux / 17076 < prev    next >
Encoding:
Text File  |  1992-11-18  |  1.3 KB  |  36 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!mcsun!sun4nl!nikhefk!wkasdo
  3. From: wkasdo@paramount.nikhefk.nikhef.nl (Willem Kasdorp)
  4. Subject: Re: rm Security Problem!
  5. Message-ID: <1992Nov18.124056.3460@paramount.nikhefk.nikhef.nl>
  6. Organization: NIKHEFK
  7. References: <1992Nov16.133710.20417@r-node.gts.org> <1e8mhlINNcij@matt.ksu.ksu.edu> <1992Nov17.215558.3558@csd.uwe.ac.uk>
  8. Date: Wed, 18 Nov 1992 12:40:56 GMT
  9. Lines: 25
  10.  
  11. root@slave.uwe.ac.uk (Operator (Phil/Dylan)) writes:
  12.  
  13. >not even close! it is a true bug,... If I find the sources for rm i'll 
  14. >recompile it,.. a true 755 rm from the sls release will delete ANY file
  15. >no matter what the owner or group is
  16.  
  17. I don't think it's in the rm sources. These kind of file operations are
  18. ultimately done by the kernel, so if there is a bug it should be
  19. in the kernel. It seems more likely to me that there is a problem
  20. with the directory permissions. For instance, /etc on my
  21. SparcStation looks like:
  22.  
  23.     drwxr-sr-x 10 bin      staff        2560 Nov 16 15:27 etc/
  24.  
  25. which is ok. But if it looks like:
  26.  
  27.     drwxrwxrwx 10 bin      staff        2560 Nov 16 15:27 etc/
  28.  
  29. you might have a problem.
  30.  
  31. Alternatively, what is the user-id of the user (guest?) you mentioned?
  32. If it's 0 (root) or bin's id then it would explain everything... 
  33. The same principle holds for the group id.
  34.  
  35.     hope this helps, Willem Kasdorp
  36.