home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.22 / text0133.txt < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.3 KB  |  47 lines
  1. Submitted-by: alex@am.sublink.org (Alex Martelli)
  2.  
  3. jik@athena.mit.edu (Jonathan I. Kamens) writes:
  4.     ...
  5.     (I assert that cat one>two keeps all permission bits on two)
  6. :You must have a pretty strange version of cat on your system, or a
  7. :brain-damaged kernel that does not clear the setuid bit when a file
  8. :is written to.
  9.  
  10. It's not the cat-s (I've tried both /bin/cat and /usr/local/gnubin/cat
  11. and I have the source to the latter so I can check), so it must be
  12. what you describe as "brain-damage" in the kernel.  Personally, I
  13. don't see why open() or write() should ever change the file's permission
  14. bits; sure it allows you to do silly things, but then if you care
  15. about security you won't keep files that are executable, and world
  16. writable, at the same time, will you?
  17. Anyway the allegedly-broken kernel is Interactive 2.2, but I believe
  18. others will behave similarly; I'll check at work.
  19.  
  20. :|> What behavior will Posix.2 mandate?
  21. :
  22. :  I believe POSIX mandates that, for security reasons, the setuid and setgid
  23. :bits on a file should be cleared whenever the file is written to.  If that
  24. :isn't in the standard, then the standard is broken; then again, we already
  25. :knew that, so it isn't a surprise.  Further, I would find it very hard to
  26. :believe that POSIX says that cat is supposed to notice if stdout is a file and
  27. :do an fstat on it before it writes to it to get the permission bits, and then
  28. :do an fchmod afterwards to restore them to their initial conditions.
  29.  
  30. It would definitely make sense that cat a>b "do the natural thing" - IF
  31. the kernel must muck with permission bit on write()s to b, then it
  32. would hardly make sense for cat to have to undo it, and viceversa, if
  33. the kernel leaves b's permission bits alone, then so should cat 
  34. (should the SHELL try to change permission bits in the redirected-to
  35. file before exec'ing cat??? I would DEFINITELY hope not!).  I have
  36. redirected followups to comp.std.unix since it seems more of a standard
  37. related question.  So, what DOES Posix say about this (open(), write(),
  38. cat, shell redirection, and permission bits), and what SHOULD it say?
  39. -- 
  40. Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
  41. Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
  42. Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; 
  43. Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
  44.  
  45. Volume-Number: Volume 22, Number 137
  46.  
  47.