🚀 go-pugleaf

Date:     Tue, 4 Feb 86 11:04:50 EST
>From: Dan Franklin <dan@BBN-PROPHET.ARPA>

I have always felt that the UNIX umask "solution" to the problem of protection
was inadequate.  If I had per-directory protections, then my personal hierarchy
would be writable only by me (644), except for my mail files which would be
even more private (600).  The source hierarchy I share with others on my
project would be read-write by the group (664).  Since all we have is umask, I
can't do this.  I must set umask to 002 so that when I work on the group source
hierarchy, others can modify my modifications.  I put up with the lessened
security in other areas because most programs implement various ad-hoc
solutions--the mail system creates all its files 600, etc.  It's not perfect;
when I use a filter on a message file in one of my MH folders, the output file
is created group-read-write.  But it mostly works.

The cd alias is a clever suggestion, but like umask, it only mostly works.
Your shell, and the shells of all the other users you ever expect to create
files in those directories, must have aliases (thus leaving out users of the
BSD Bourne shell and the System V.1 shell) and it doesn't work with commands
like "find," which can recurse over a hierarchy and create files (via -exec)
without ever forking a shell of any kind.  Some daemons don't exec shells,
or only exec the Bourne shell (/etc/rc, for instance).

However, just because umask is inadequate doesn't mean this committee should
try to fix the problem.  This inadequacy is not widely enough recognized to
justify creating a brand-new scheme in a standards document without testing it.
Also, the standard would (I think) have to retain umask in its current form;
and having two ways to do the same thing is always unfortunate.  Other
submitters have also raised good points about compatibility (tar and cpio).  So
much as I like the idea, I think it has to be left for innovators to try
adding, not for a standard.

[ No one has proposed changing umask in a standards document.  -mod ]

	Dan

Volume-Number: Volume 5, Number 35