Re: Private groups
Stephen White writes (BTW, there's no need to shout):
> Ian Jackson writes:
> IJ> False. Quite a lot of activity happens in /tmp and /usr/tmp,
> IJ> on my system at least.
>
> This is a non-argument. It is completely irrelevant to the issue. The entire
> purpose of the uid=gid argument is so people can share files with each other
> _within their own (or project) directories_.
I see that you have `conveniently' elided the part of your message I
was responding to:
> [Ian Jackson writes:]
> > Stephen White writes:
> > > ...
> > > And [the] directories [which would be setgid] is [sic] where all the
> > > action occurs. With the setgid scheme, virtually all activity will
> > > be conducted under BSD semantics anyway.
> >
> > False. Quite a lot of activity happens in /tmp and /usr/tmp, on my
> > system at least.
You claimed that all the action occurs in directories which would be
setgid, and implied that only project and user home directories would
be.
Your claim was false, so the argument you based on it was unsound.
I shall now deal with the rest of your posting.
> Why is there a ... requirement to have SysV semantics within /tmp and
> /usr/tmp?
If we use a umask of 002 or some such and mount /tmp &c with BSD
semantics it will be necessary to make /tmp group-owned by a group
such as `root' or `system' that no unpriveliged users are members of.
This is required as all files created in /tmp will otherwise be
writeable by the unpriveliged users of the group which owns /tmp.
Therefore, files in /tmp will be owned by this `system' group rather
than the groups of the users who created the files.
Now, in general, if we adopt the private groups scheme the most
important part of the ownership of a file will no longer be the user
ownership but the group ownership, as that is what will control write
access to most files, and also read access to most private files.
My first argument in this message against BSD semantics in /tmp is
that this violates the general rule in my previous paragraph. If this
is done some files will have their access controlled by the group
ownership and some by the user ownership.
My second argument in this message against BSD semantics is that it is
generally less expected than System V semantics. When using SysV
semantics the setgid bit gives you a clear indication that something
is happening to the group ownerships around the directory. When using
BSD semantics this will be less clear, and the behaviour will
therefore be further from that which might be expected.
> Can you explain how BSD managed all these years if SysV semantics are
> such a requirement for /tmp?
Neither of the two arguments I make above apply in a traditional BSD
system with a umask of 022 or similar. The first argument doesn't
apply because group ownership is generally irrelevant on such a system
- access is controlled by user ownership. The second argument doesn't
apply for this reason as well, and also because `ls' doesn't show the
group ownership by default on BSD, thus hiding the unexpected
behaviour (out of sight, out of mind).
> The fact remains that uid=gid is merely a disguised BSD filing
> system.
uid=gid has nothing to do with it.
> SW> It's so much easier to just mount the drive with bsd semantics
>
> IJ> The reason not to do this has been explained by Matthew Hannigan
> IJ> and myself in considerable detail. You have not refuted our
> IJ> arguments.
>
> Incorrect. The one argument against mounting with BSD consituted of "What
> happens if the admin sees the parameter in fstab and removes it?".
You have obviously not been reading the list.
In <[🔎] 199403120410.OAA27987@extra.ucc.su.OZ.AU> on Fri, 11 Mar 94 at
20:14 PST, Matthew Hannigan <matth@ucc.su.oz.au> wrote on the
debian-devel list:
] I strongly agree. If you use the bsd _mount_ options then:
]
] 1. You can't get back the V7 semantics back for
] individual directories.
] 2. You're changing things for users without making
] the change manifest. (i.e. it seems as if
] you're trying to sneak a change past the users)
] 3. It can be too easily turned off by an administrator
] (Users start to rely on the bsds semantics then
] one day some admin looks at fstab and thinks,
] hey what does this do? I think I'll take it
] out (or not remember to put it in when modifying it))
In <[🔎] m0pfopW-0002dGC.ijackson@nyx.cs.du.edu> on Mon, 14 Mar 94 at
10:49 PST, I wrote on the debian-devel list:
] 4. It violates the principle of least surprise. Files will be created
] (with a umask of 002, remember) with odd group ownership for no
] readily apparent reason. The same could be said of setgid, but the
] g+s bit in the directory permissions is much more visible and is the
] kind of thing that people would believe might have this effect.
]
] This could be seen as another facet of Bradley Bosch's argument and
] Matthew Hannigan's reason 1 (that using BSD you can't get the V7
] semantics back for individual directories). Using setgid allows
] selection on a directory-by-directory level; whereas using bsd
] semantics allows selection on a system-by-system level.
]
] The question is really which is most likely to be required, and how
] much effort it is to work around if one needs something that's not
] provided.
]
] I believe that we're much more likely to want to turn off this feature
] for individual directories (/tmp and /usr/tmp come to mind
] immediately). In practice, I don't think that many sysadmins would
] bother turning it off even if we made it easy by mounting everything
] bsd-style.
These arguments have not been refuted.
I think you would benefit from reading the alt.atheism FAQ file on how
to construct a logical argument. It can be found on rtfm.mit.edu in
/pub/usenet/news.answers/atheism/logic.
Ian.
Reply to: