PRIVATE GROUPS 2/2
SW> Can you explain how BSD managed all these years if SysV semantics
SW> are such a requirement for /tmp?
IJ> Neither of the two arguments I make above apply in a traditional
IJ> BSD system with a umask of 022 or similar. The first argument
IJ> doesn't apply because group ownership is generally irrelevant on
IJ> such a system - access is controlled by user ownership.
This argument relies on your arbitrary rule being accepted as fact.
IJ> The second argument doesn't apply for this reason as well,
And hence also relies on accepting your arbitrary rule as fact.
Despite this, it still remains irrelevant if the group ownership is
"fred" or "root" in the /tmp directory. If the group ownership is "fred",
then only fred and root can access the file. If the group ownership is
"root", then only fred and root can access the file. Notice the
difference? No, neither did I.
If fred wanted to share the file in /tmp, then, regardless of SysV or BSD
semantics in the /tmp directory, it is the "other" permission field that
is important. Therefore, it is irrelevant whether the /tmp directory is
operating under SysV or BSD semantics.
IJ> and also because `ls' doesn't show the group ownership by default
IJ> on BSD, thus hiding the unexpected behaviour (out of sight, out
IJ> of mind).
Weak.
SW> The fact remains that uid=gid is merely a disguised BSD filing
SW> system.
IJ> uid=gid has nothing to do with it.
I am aware of that. I was using the common name that has been applied to
the argument. Your personal prejudice against the name shouldn't prevent
you from understanding what I am saying.
I had not addressed the issue of making gid numbers equal uid numbers in
my entire message, so your misunderstanding is difficult to comprehend.
Would you understand if I rephrased it to: "The fact remains that the
entire scheme of setgid bits on directories is merely a disguised BSD
filing system"?
SW> Incorrect. The one argument against mounting with BSD consituted
SW> of "What happens if the admin sees the parameter in fstab and
SW> removes it?".
IJ> You have obviously not been reading the list.
Would you understand if I rephrased it to: "The one significant argument
against..."? This is unbearably misusing the word "significant", I admit.
MH> 1. You can't get back the V7 semantics back for
MH> individual directories.
You haven't explained why this is important.
MH> 2. You're changing things for users without making
MH> the change manifest. (i.e. it seems as if
MH> you're trying to sneak a change past the users)
Weak.
MH> 3. It can be too easily turned off by an administrator
MH> (Users start to rely on the bsds semantics then
MH> one day some admin looks at fstab and thinks,
MH> hey what does this do? I think I'll take it
MH> out (or not remember to put it in when modifying
MH> it))
Pathetic.
IJ> 4. It violates the principle of least surprise. Files will be
IJ> created (with a umask of 002, remember) with odd group ownership
IJ> for no readily apparent reason.
I have already dealt with the fallacy of your argument of "least
surprise".
IJ> The same could be said of setgid, but the g+s bit in the
IJ> directory permissions is much more visible and is the kind of
IJ> thing that people would believe might have this effect.
And I have dealt with this above.
IJ> I believe that we're much more likely to want to turn off this
IJ> feature for individual directories (/tmp and /usr/tmp come to
IJ> mind immediately).
You haven't provided a concrete reason why, other than your refutations
based on an arbitrarily defined rule.
IJ> In practice, I don't think that many sysadmins would bother
IJ> turning it off even if we made it easy by mounting everything
IJ> bsd-style.
And here, you go against your own argument.
IJ> I think you would benefit from reading the alt.atheism FAQ file
IJ> on how to construct a logical argument. It can be found on
IJ> rtfm.mit.edu in /pub/usenet/news.answers/atheism/logic.
By now it should be obvious that you need to read this more than I do.
Skimming through one of my text books, I find the flaws in your arguments
have the following names:
1) Circulus in probando. Your reasoning begins with basic assumptions
that cannot be proven except by proceeding to other conclusions
which are based on those assumed in the beginning.
2) The fallacy of sophistical refutations. To ridicule an argument, to
exaggerate its claims so as to attack a "straw man" is another
fallacy of irrelevancy. It may involve attributing to another a view
that he does not hold.
The dismissal of your nerdy little insult over with, back to the
discussion. These are the essential facts:
Users will conduct virtually all their activities under BSD semantics.
User directories, source directories, and project directories. Note, that
/tmp is irrelevant.
Therefore the argument is, and only is, "Do we need SysV semantics at
all, knowing that BSD semantics are already in effect for virtually all
file operations?"
If it can be demonstrated that SysV semantics are required and the
benefits outweigh the extra complexity of a mixed BSD/SysV filing system,
then, by all means, setgid is the way to go, otherwise there is no
purpose in complicating things unnecessarily.
Implementing the user groups proposal with with BSD semantics is trivial.
Shove in a "grpid" in fstab, and make a small change in adduser. The
filing system remains homogeneous, permissions remain familiar, very
little explanation would be required in the Debian FAQ, and almost
everyone lives happily ever after. :)
Reply to: