std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/03/86)
>From seismo!gatech!astrovax!fisher!djl Mon Feb 3 11:28:40 1986
Date: Mon, 3 Feb 86 02:00:12 est
As a big fan of least common denominator, rather than feeping creaturism,
I would note that it is quite easy to get umask/dir, by simply using
the facilities provided by your shell. For instance, using csh,
alias cd to do 'source .exitdir; cd \!* ; source .enterdir' , and
use the shell scripts called .enterdir and .exitdir to do directory
specific initializations.
***dan
[ Since I'm taking sides on this, I'm going to post my comments
as a followup by jsq instead of notes by the moderator. -mod ]
{allegra,astrovax,princeton}!fisher!djl
The misplaced (That car sure is rusty!) Californian
Volume-Number: Volume 5, Number 29std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/03/86)
>From: jsq@sally.utexas.edu (John Quarterman) Date: Mon, 3 Feb 1986 12:00:13 CST > As a big fan of least common denominator, rather than feeping creaturism, > I would note that it is quite easy to get umask/dir, by simply using > the facilities provided by your shell. For instance, using csh, > alias cd to do 'source .exitdir; cd \!* ; source .enterdir' , and > use the shell scripts called .enterdir and .exitdir to do directory > specific initializations. > > ***dan To set up a source tree so that everybody used the same umask on it with your method would require everybody to change their .cshrc. To do it with real umask per directory would require only setting the umask for the directory. The latter looks more like the least common denominator to me. The more interesting question is *how* do you set a umask on a directory? Do you try to derive the bits from the directory mode bits in some way, such as setgid means apply the group mode bits as the mask? Or do you have to have an extra word in the inode? Or do you do it by a file in the directory? And how do you get the umask inherited by child directories? I would think the preferred approach would be to somehow derive the umask from the directory mode bits. Inheriting could be done by just setting the umask for all the subdirectories with find. Except that mkdir should likely make sure the umask were inherited. One wonders if most of the people for umask per directory are using 4.2BSD or 4.3BSD and those against are using other systems. The desirability becomes obvious after you get used to the 4.2BSD method of assigning the group of a new file according to the group of its parent directory. Volume-Number: Volume 5, Number 30
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/05/86)
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 35std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/06/86)
Date: Thu, 6 Feb 86 06:06:25 EST >From: Alex Dupuy <dupuy%garfield@COLUMBIA.EDU> Organization: Columbia University In <4103@ut-sally.UUCP> std-unix@ut-sally.UUCP (John Quarterman) writes: > > The more interesting question is *how* do you set a umask on a directory? Do > you try to derive the bits from the directory mode bits in some way? ... And > how do you get the umask inherited by child directories? > > I would think the preferred approach would be to somehow derive the umask > from the directory mode bits. Inheriting could be done by just setting the > umask for all the subdirectories with find. Except that mkdir should likely > make sure the umask were inherited. Having primarily used bsd Unix for a few years, and before that, Twenex, which has default file protections on a per-directory basis, I would agree that keeping the protection masks in the directory tree is better than the Unix's umask. Still, as some have pointed out, for reasons of compatibility with tar and cpio, adding information to the directory structures would be a mistake. Also, switching over to a purely directory based umask would cause security problems with existing programs expecting umask to work properly. A directory/process based umask scheme which provides compatibility with the normal Unix filesystems, and allows naive programs to operate securely (when opening files in /tmp or /usr/tmp, say) is still possible, and would provide a more flexible mechanism than the common directory based systems. It might work like this: The setuid and setgid bits in the mode of a directory would be used to specify which logical combination of umask and directory mode access bits should be used as the mask when creating files or directories. The logical combinations would be 00 mask = umask 01 mask = umask | ~directory mode 10 mask = umask & ~directory mode 11 mask = ~directory mode Users would set their umasks much as they do now, to cover the default case. Directories like /tmp would be set 00 for security compatibility, while mail directories would be set 01 for greater protection, project directories would be set 10 to ensure that files and subdirectories were group writable, and home directories might be set 11. For the benefit of really paranoid programs/users, two bits could be added to the umask to override the directory combination bits, although doing so would add to the complexity of the system without really increasing security or flexibility. @alex Volume-Number: Volume 5, Number 41