home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0034.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.0 KB
  1. Date:     Tue, 4 Feb 86 11:04:50 EST
  2. >From: Dan Franklin <dan@BBN-PROPHET.ARPA>
  3.  
  4. I have always felt that the UNIX umask "solution" to the problem of protection
  5. was inadequate.  If I had per-directory protections, then my personal hierarchy
  6. would be writable only by me (644), except for my mail files which would be
  7. even more private (600).  The source hierarchy I share with others on my
  8. project would be read-write by the group (664).  Since all we have is umask, I
  9. can't do this.  I must set umask to 002 so that when I work on the group source
  10. hierarchy, others can modify my modifications.  I put up with the lessened
  11. security in other areas because most programs implement various ad-hoc
  12. solutions--the mail system creates all its files 600, etc.  It's not perfect;
  13. when I use a filter on a message file in one of my MH folders, the output file
  14. is created group-read-write.  But it mostly works.
  15.  
  16. The cd alias is a clever suggestion, but like umask, it only mostly works.
  17. Your shell, and the shells of all the other users you ever expect to create
  18. files in those directories, must have aliases (thus leaving out users of the
  19. BSD Bourne shell and the System V.1 shell) and it doesn't work with commands
  20. like "find," which can recurse over a hierarchy and create files (via -exec)
  21. without ever forking a shell of any kind.  Some daemons don't exec shells,
  22. or only exec the Bourne shell (/etc/rc, for instance).
  23.  
  24. However, just because umask is inadequate doesn't mean this committee should
  25. try to fix the problem.  This inadequacy is not widely enough recognized to
  26. justify creating a brand-new scheme in a standards document without testing it.
  27. Also, the standard would (I think) have to retain umask in its current form;
  28. and having two ways to do the same thing is always unfortunate.  Other
  29. submitters have also raised good points about compatibility (tar and cpio).  So
  30. much as I like the idea, I think it has to be left for innovators to try
  31. adding, not for a standard.
  32.  
  33. [ No one has proposed changing umask in a standards document.  -mod ]
  34.  
  35.     Dan
  36.  
  37. Volume-Number: Volume 5, Number 35
  38.  
  39.