edler@cmcl2.NYU.EDU (Jan Edler) (11/05/87)
In 4.[23]bsd, when you create a file, the gid of the file is taken from the gid of the directory you create it in (even if you aren't a member of that group). It seems to me that the single umask(2) mechanism is crippled in this environment. If I work in several different groups, and I don't want my files in each group created with the same group permissions, I have to change the umask every time I switch back and forth between working on different groups; a situation akin to that which motivated the establishment of multiple groups in the first place (elimination of the newgrp command). The only alternatives I can think of are: - Allow a separate umask in the kernel for each group a user is a member of. An extra umask would also be needed for groups that the user is not a member of. - Add a file mode mask to each directory, to apply for all files created there. With either of these alternatives, the existing umask could remain as well, so that the mode of a newly created file would be influenced by two masks; this would help make either change upward compatible, since users happy with the old semantics could just ignore the new masks (leave them 0). Any thoughts on this? Other ideas? Does everyone think things are fine the way they are? Were multiple groups a bad idea? Jan Edler edler@nyu.nyu.edu ...!cmcl2!edler
flee@gondor.psu.edu (Felix Lee) (11/07/87)
In article <21241@cmcl2.NYU.EDU> edler@cmcl2.UUCP (Jan Edler) writes: >In 4.[23]bsd, when you create a file, the gid of the file is taken from >the gid of the directory you create it in (even if you aren't a member >of that group). It seems to me that the single umask(2) mechanism is >crippled in this environment. I think one obvious answer is to have a file inherit the protections of the directory it's created in (file_mode & ~umask & dir_mode); inheritance of protection, like inheritance of group. Minimal disruption--no extra structures to worry about. >Were multiple groups a bad idea? I don't know. I'd rather not have to type 'newgrp'. But looking at the groups I'm in now, only two of them are exercised regularly. Most get occasional use, when I'm working in a specific domain. A few, like printer permission groups, are never used. I can't imagine ever needing all 24 groups that our installation allows. However, it would be a pain to switch back and forth between the two groups I do use regularly. I think I'd be happy with a small group vector, and a 'newgrp' command to switch in groups as I need them. But this is just added complexity. -- Felix Lee flee@gondor.psu.edu {cbosgd,cmcl2}!psuvax1!gondor!flee
preece%xenurus@gswd-vms.Gould.COM (Scott E. Preece) (11/10/87)
What I've done is to make my umask change as I change directories.
Thanks to aliases, this is no big deal. I do all my directory movement
through aliased commands, which do things like remembering the last
directory I was in, changing my prompt to show the directory I'm in,
and set the umask. I only use two umasks, one for directories in my
home tree and one for anything else, but it would be trivial to check
for other paths and set appropriate umasks (or check the gid of the
target directory and key off that).
The umask manipulation is done by the um command in each of the actual
directory-changing aliases. The dirs command is there for the benefit
of GNU emacs shell sessions. The prompthead variable is assumed to have
been set somewhere up above (I usually use the name of the machine the
session is on, with highlighting around it tailored to the terminal I'm
using).
set prompt="$prompthead$cwd:t>"
alias um 'eval umask 2`if ("$cwd" =~ *${user}*) echo 2`'
alias back 'set back=$old; set old=$cwd; cd $back; um; unset back'
umask 022
alias cd ' set old=$cwd;chdir \!*; um; set prompt="$prompthead$cwd:t>"; dirs'
alias ">" ' pushd \!*; um; set prompt="$prompthead$cwd:t>"; dirs'
alias "<" ' popd; um; set prompt="$prompthead$cwd:t>"; dirs'
alias ".." ' cd ..; um; set prompt="$prompthead$cwd:t>"'
alias mark 'set \!:1=`pwd`; alias \!:1 cd $\!:1'
alias Mark mark \!:1 \; echo '>> ~/.cshrc' set \!:1 = `pwd` \\\; alias \!:1 cd '$'\!:1
--
scott preece
gould/csd - urbana
uucp: ihnp4!uiucdcs!ccvaxa!preece
arpa: preece@Gould.comsnoopy@doghouse.gwd.tek.com (Snoopy) (11/12/87)
In article <21241@cmcl2.NYU.EDU> edler@cmcl2.UUCP (Jan Edler) writes: >In 4.[23]bsd, when you create a file, the gid of the file is taken from >the gid of the directory you create it in (even if you aren't a member >of that group). It seems to me that the single umask(2) mechanism is >crippled in this environment. I agree, this is a pain. > - Allow a separate umask in the kernel for each group a user > is a member of. An extra umask would also be needed for > groups that the user is not a member of. Should a chgrp then do a chmod for you? (Probably not.) > - Add a file mode mask to each directory, to apply for all > files created there. Perhaps just using the mode of the directory as an additional mask would work well. Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com
acheng@uiucdcsm.cs.uiuc.edu (11/12/87)
>/* Written 10:04 pm Nov 6, 1987 by flee@gondor.psu.edu in uiucdcsm:comp.unix.wizards */ >I think one obvious answer is to have a file inherit the protections of the >directory it's created in (file_mode & ~umask & dir_mode); inheritance of >protection, like inheritance of group. Minimal disruption--no extra >structures to worry about. The mode of directory is usually quite different from its files. For one thing, all directories must have at least one x-bit on but most files have all x-bits off. If all created files inherite that x-bit, am I up for suprises since I have "." at the beginning of my $PATH. Other problems: /tmp is "rwxrwxrwx" but I definitely do not want all my /tmp/* files to be other-writable. Another case: I may make my $HOME/bin to be other-searchable (i.e. rwx--x--x) to share my private tools with other users only if they know the exact name without letting them browse through it. But if the tool is a shell script, the read-bit must be on. Inheritance of mode from directory will give more troubles than its worth. ---------------------------------------------------------------------- Albert Cheng acheng@a.cs.uiuc.edu (ARPAnet or CSNET) uiucdcs!acheng(USENET) Dept. of Computer Science, Univ. of Illinois-Urbana, Rm. 240, 1304 W. Springfield, Urbana, IL 61801, USA. %%% THE ABOVE IS MY OPINION STOP %%%
snoopy@doghouse.UUCP (11/19/87)
In article <9100007@uiucdcsm> acheng@uiucdcsm.cs.uiuc.edu writes: >> (file_mode & ~umask & dir_mode) >The mode of directory is usually quite different from its files. For >one thing, all directories must have at least one x-bit on but most >files have all x-bits off. If all created files inherite that x-bit, >am I up for suprises since I have "." at the beginning of my $PATH. You misunderstand. The mode of the directory would be used as a second mask, it would not be stuffed in directly. Example: I have my umask set to 022, I create a file in a directory that is mode 770: file_mode = 666 /* default before any masking */ umask = 022 /* turn off write permission to group and other */ ~umask = 755 dir_mode = 770 /* turn off all permission to other */ The file is created as mode 640, not mode 770. In practice, one might set their umask to 002, their home directory to mode 700, and group project directories to mode 770. Then everything created under your home directory would be completely safe, everything in the group project directory could be used by anyone in the group, and files created in public directories like /tmp could be read by anyone. There are still cases where you'd need to do a chmod, but it would be better than what we have now. Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com NFS: No Frigging Security