umask per dir
Moderator, John Quarterman
std-unix at ut-sally.UUCP
Wed Feb 5 07:16:28 AEST 1986
Date: Tue, 4 Feb 86 11:04:50 EST
>From: Dan Franklin <dan at 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
More information about the Mod.std.unix
mailing list