Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!news.ans.net!cmcl2!prism.poly.edu!kapela From: kapela@poly.edu (Theodore S. Kapela) Subject: Re: bug with ufs file creation (Not!) Message-ID: <CD1BF5.JMM@poly.edu> Summary: Apples and Oranges Organization: Polytechnic University, New York References: <CCyLF6.n6@kithrup.com> <CCz5n2.9v7@pilhuhn.sub.org> <GMT07Sep.93.34239@work1.rhrz.uni-bonn.de> Date: Wed, 8 Sep 1993 12:16:16 GMT Lines: 54 In article <GMT07Sep.93.34239@work1.rhrz.uni-bonn.de> juengst@saph2.physik.uni-bonn.de writes: >In article <CCz5n2.9v7@pilhuhn.sub.org>, hwr@pilhuhn.sub.org (Heiko W.Rupp) writes: >>sef@kithrup.com (Sean Eric Fagan) writes: >>>*I* consider this a bug. It exists in every Net/2-derived system I could >>>play with, including BSD4.4. When creating a file, the gid given to the >>>file is the gid of the directory it is in, and not the gid of the process >>>creating the file. The following patch fixes that; it will only use the >>>gid of the directory if the directory's SGID bit is set. >> >>If I remember right, this is a feature of all BSD-derived systems, so >>I wouldn't change this. > >DG/UX 5.4.2 (a SVR4) creates new files with the GID of the process if >there's no SGID bit set for the directory. Otherwise the SGID for directories >would be useless. I think Sean Eric Fagan is right. First, you are comparing BSD and System V here (You say so yourself in the first line). These are two different systems, so comparing one to the other is like comparing apples and oranges. BSD Net/2 (and its derived systems) use standard BSD semantics for file creation (makes sense - BSD follows its own rules). If you will also notice, most strictly-BSD systems do *NOT* have a "newgrp", whether it is a separate executable, or a shell builtin. The only purpose of this is to change the group of new files created. Since BSD uses the GID of the dir and not the process, newgrp isn't needed, and is useless. System V creates files with the same group as the current "primary active" group. BSD creates files with the same group as the parent directory. PERIOD. What many vendors (including Sun) do is provide *both* policies. Sun chose to use the SGID bit to indicate file creations under that directory are to follow BSD semantics (which is why the SGID bit is set on new subdirs created under that dir). (And YES, the SGID bit in most BSD systems means nothing on a directory) Since 386BSD is *BSD*, and *NOT* System V, and it is *NOT* a cross/blend of System V and BSD, it should (and *does*) follow BSD policies. Now, if there are those that like the idea of using the SGID bit to indicate how group membership of a file should be chosen, then they may implement this patch. DO *NOT*, however, CALL THIS A BUG OR MIS-FEATURE. The software works AS INTENDED. Now, I wish people would stop assuming SunOS is the definitive Unix or BSD, since it is *neither*. Just because XXX OS does something does not mean it is right. -- Theodore S. Kapela Center for Applied Large-Scale Computing Polytechnic University kapela@poly.edu