karish@forel.stanford.edu (Chuck Karish) (10/21/89)
In article <38688@wlbr.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM.UUCP (Steven M. Schultz) wrote: >>In article <20258@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >>>In article <1344@accuvax.nwu.edu> rico@dehn. (Rico Tudor) writes: >>> (3) What purpose is served by taking the group ID of a newly >>> created file from the parent directory, rather than the >>> process? >> >>Given that `the process' may be in up to 8 (4.2BSD) or 16 (4.3BSD) >>groups simultaneously, there is no single correct choice based on >>the process alone, hence the parent directory rule. Another reason is that it makes it practical to explain to users how group IDs are assigned. There's no standard UNIX utility that tells me what my effective group ID is. > Another way of looking at the multi-group capability is that > a process has a main/primary group - the one listed in the > password file and multiple secondary groups as determined by > the group file. It makes sense to me to use the primary > group for purposes of file ownership. Directories such as /tmp > typically are owned by groups of which users are not members, this > has led to surprises at least once for me. This is fine as long as all you want from groups is a way to have your daemons cooperate with one another. The BSD supplementary groups system makes it possible for users to both protect and share resources. The mechanism is easy to explain and can be set up once for each directory tree to be shared, after which it works transparently for users who are members of the group. The rules are: - Set the desired group access for the directory to be shared. - Don't muck with your umask (must be 002). This makes it possible for me to be a member of group `graphics' and of group `geochem', and to share files with each group. I can do this without having to remember to reset my effective group ID every time I write a file in one of the shared directories. For the ultimate in convenience, if I am the only member of my own supplementary group, I can protect files from any group access without changing my umask or using chmod. As far as the /tmp example is concerned, there are problems under the inherit-from-EGID scheme too, unless all users have the same default group. <->-<->-> Some computer system vendors are starting to use a system that allows anyone to choose whether the parent directory or the effective group ID of the process will be used in a given directory and its dependent directories. The mechanism used is to set the set-GID bit for the directory. If it is set, files and directories inherit their group ID from the parent directory, and new directories have the set-GID bit on by default. Fine so far; the user can choose on a directory-by-directory basis whether to confirm to SVID or BSD/FIPS-151A behavior. The problem is that the system is not robust. It requires that the user and the programmer take extraordinary precautions to avoid resetting the set-GID access bit for directories. Scripts and commands that say `chmod 775 dirname' or `chmod ug=rwx,o=rx' are liable to turn off the bit, unless the chmod utility is modified to look for it. In C, the safe way to change access modes for a directory becomes stat("dirname", &dirstat); chmod("dirname", <my_modes> | (dirstat.st_gid & (~(S_IRWXU | S_IRWXG | S_IRWXO)))); where <my_modes> is the desired set of access bits. Since POSIX 1003.1 leaves the interpretation of the set-UID and set-GID bits on directories up to the implementation, this approach is a good idea anyway. Even so, under the new system for choosing defaults, existing code that does not take these precautions can break the access control system inadvertently. It becomes unworkably cumbersome to make proper use of supplementary groups. Users will not notice the problem unless they actively look for it, and files will not be protected the way their owners think they're protected. How else could this be handled? - Pick one of the two styles, maybe on a per-host basis, and stick to it. - Set the flag by a mechanism that doesn't overload an existing one. - Replace the access control system with a more flexible and capable (and, undoubtedly, less efficient) one. - Have chmod() ignore requests to modify the set-UID and set-GID bits on directories. Provide a separate function to set these bits. Suggestions, anybody? Remember, the solution has to work for vendors who sell to SVID shops, to BSD shops, and to the government, and should preserve as much existing code and user experience as possible. Chuck Karish karish@mindcraft.com (415) 493-9000 karish@forel.stanford.edu
guy@auspex.auspex.com (Guy Harris) (10/24/89)
>Another reason is that it makes it practical to explain to users how >group IDs are assigned. There's no standard UNIX utility that tells me >what my effective group ID is. Yes, unfortunately older UNIX systems and systems have haven't picked up "id" don't have it.... >The problem is that the system is not robust. It requires that the user >and the programmer take extraordinary precautions to avoid resetting the >set-GID access bit for directories. Scripts and commands that >say `chmod 775 dirname' or `chmod ug=rwx,o=rx' are liable to turn off >the bit, unless the chmod utility is modified to look for it. At least in the first case, the SunOS "chmod" has been changed; to quote the 4.0.3 CHMOD(1V) Absolute Modes An absolute mode is an octal number constructed from the OR of the following modes: ... 2000 Set group ID on execution (this bit is ignored if the file is a directory; it may be set or cleared only using symbolic mode). so "chmod 775 dirname" would preserve the setting of the set-GID bit. As for the second case, I almost never forcibly set modes with "chmod"; I usually turn them on and off with "+" and "-", so that's not a problem. If you want to do the moral equivalent of "chmod 775" symbolically - i.e., leave the set-GID bit alone, but force the directory to have owner and group read/write/execute and other read/execute permission, you can do chmod ug+rwx,o-w,o+rx dirname >How else could this be handled? > > - Pick one of the two styles, maybe on a per-host basis, and stick to it. SunOS does have a "grpid" mount-time flag that forces the 4.[23]BSD semantics for all directories on that file system, regardless of the state of the set-GID bit.