BSD mount vs. Setgid - reply to Stephen White
(Readers not interested in flamewars will find this message most tedious.
Unfortunately it seems I have to go into considerable detail to
make myself understood by Stephen White.)
> IJ> I see that you have `conveniently' elided the part of your
> IJ> message I was responding to:
>
> It was "`conveniently' elided" to keep quotes to a minimum - or do you
> prefer the B1FF style of quoting? I also "elide" (sic) irrelevant issues
> to keep the basic discussion clear and understandable. I find that the
> biggest handicap for any exchange of opinions is trying to debate every
> point of contention.
I prefer to have enough quoted material so that the arguments that are
being made can be followed. If you delete the context statements
become meaningless.
If you don't want to debate a point of contention then don't debate
it; don't quote the last few lines and add some meaningless
`refutation'.
>From this point on I shall mark quoted text that I have reinserted to
provide relevant context with `}' symbols. I have also reedited
things to a more usual Usenet-style quoting, as this allows the proper
chronology and relationship of messages to be seen.
BTW, according to Chambers English Dictionary:
elide ... v.t. to rebut (arch.): to cut off, as a syllable: to
suppress, abridge. n. elision (...) ... . [L. elidere, elisum -e,
from laedere, to strike.]
It seems that I overestimated your reading level and initiative
(presumably you have access to a dictionary).
Stephen White writes:
} [Ian Jackson writes:]
}} Stephen White writes:
}}} [Ian Jackson 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.
>>>
>>> This is a non-argument. It is completely irrelevant to the issue.
>>
}} 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.
}
> The rebuttal was not denying that activity occurs in /tmp. It was denying
> the relevance of such activity to the setgid vs BSD mount discussion.
You appear to be confused as to who was producing an argument and who
was rebutting it. As can be seen above, you argued that:
"[virtually] all activity occurs in setgid dirs" =>
"[virtually] all activity occurs in BSD semantics"
However, your premise was false and your argument therefore unsound.
When I pointed this out your replies became nonsensical.
It is possible that you are trying to express the argument:
"all the relevant activity occurs in setgid dirs" =>
"all the relevant activity occurs in BSD semantics"
Unfortunately you must then justify your assertion that the activity
in /tmp is not relevant; you have not yet done so. (To say that it is
not relevant because it doesn't happen in a setgid directory would be
circular, of course.)
> It appears that you base your claim on the following:
>
>>>>> And [the] directories [which would be setgid] is [sic] where
>>>>> all the action occurs.
>
> Please note that the []'d portions are your additions, and those
> additions change the meaning of my statement. This is a dishonest tactic,
> Ian.
Firstly, it has taken you a long time to spot this. If my quote had
been a misquote it would have saved a lot of aggravation if you'd
bothered to read my message several exchanges ago. However, it's not
even true that I have misleadingly quoted you. See below.
Furthermore you have no basis for your claim that it was a `dishonest
tactic' on my part - to substantiate this you must show that I
deliberately intended to mislead. I demand that you substantiate your
claim of dishonesty on my part or withdraw it and apologise forthwith.
Here is what Stephen White wrote, that he claims I misleadingly
edited (I have reformatted it to fit in 80 columns):
}}}}} So, what exactly are the setgid's being used for? Answer; to create BSD
}}}}} semantics for selected directories, those being the user directories and
}}}}} project directories.
}}}}}
}}}}} And those directories is where all the action occurs. With the
}}}}} setgid scheme, virtually all activity will be conducted under
}}}}} BSD semantics anyway.
My edits were to delete the first paragraph, as it wasn't part of the
context I wished to quote, and then to replace the word `those'
applied to `directories' with `the ... which would be setgid'.
`those directories' refers to the `selected directories' from the
previous paragraph, which are precisely the directories that in my
scheme would be setgid, hence `the ... which would be setgid'.
Perhaps you would like to explain in what way I changed your meaning.
>> Why is there a ... requirement to have SysV semantics within /tmp
>> and /usr/tmp?
>
> Would you please stop changing _my_ text in your quotes?
>
> The "..." replaces the single word "continuing", and without that word it
> looks as though I'm asking why SysV semantics were created for the /tmp
> directory. I can only assume that this effect was deliberate, as there
> was certainly no space saved by your modification.
I deleted the word `continuing' because I didn't see how it affected
the meaning. I try to trim text down to the minimum which will have
the same meaning, so that those trying to follow the argument have to
lead less `extraneous' material. This is perfectly acceptable
practice. If you don't believe me go and read
news.announce.newgroups.
I always expect that, when people do this, if the quoted poster feels
they've been misquoted they'll speak up, as you have now done.
However I'm afraid I still fail to see the difference which the word
`continuing' makes to the meaning of your sentence.
I don't see the difference between asking `why SysV semantics were
created for the /tmp directory' (interpreting this sentence as close
as possible to something reasonable) and asking `why SysV semantics
are required for the /tmp directory', or indeed `why SysV semantics
are still required for the /tmp directory'.
>> 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,
>>
>> My first argument in this message against BSD semantics in /tmp
>> is that this violates the general rule in my previous paragraph.
>
> This is a rather arbitrary rule, which ignores the fact that only the
> owner of a file can chmod its permissions.
It's not an arbitrary rule, it's a rule derived from observation.
Your point about chmod is irrelevant; a user who does not own the file
but can write it and the containing directory (this is the usual case
- remember, I said `most important', not `only important') can easily
replace the file with another with the same contents owned by
themselves. In almost all circumstances this will have the same
effect as a chmod.
>> My second argument in this message against BSD semantics is that
>> it is generally less expected than System V semantics.
>
> About as unexpected as setgid bits on directories, Ian.
Setgid bits on directories are *visible* directly. BSD semantics are
only visible by their effect (and by looking in the fstab).
BSD semantics do things behind your back; setgid directories do it up
front where you can see it and turn it on and off.
Things that do things behind your back are usually much less expected
than those that give an indication of their presence.
>> When using SysV semantics the setgid bit gives you a clear
>> indication that something is happening to the group ownerships
>
> It is only clear if you look, and know about setgid.
If you don't look you won't see the group ownerships at all -
presumably in that case you don't care at all. If you don't know
about setgid finding out is not hard.
> You are advocating a mix of SysV and BSD and claiming it will have a more
> expected behaviour?
I am advocating an *explict* specification of the semantics of each
directory rather than an *implicit* specification in the fstab.
Any software engineer and user interface designer will know how
important explicitness is.
More explict specification produces expected behaviour more often,
because the specification is visible before the behaviour.
> To find out the group ownership of a created file under setgid:
> 1) ls -ld ..
You mean `ls -ld .'
> 2) Check the setgid bit.
> [interpret the results]
>
> Under BSD mount, it is simply:
>
> 1) The group of the created file is always the same as the group of the
> directory.
You have forgotten the requirement to look in the fstab. You must
count that in the instructions for BSD mount. Since BSD semantics
have been unusual in the Linux community so far and are unobvious to
newcomers to Unix you'll probably find that most people don't look in
the fstab.
The obvious place to look for information about what is going to
happen is to look nearby - in this case at the permissions of the
directory and the ids of the process. Looking at the fstab is a bad
thing in this context, because it is not the obvious place except for
refugees from BSD systems.
Here starts the response to Stephen White's message entitled
"PRIVATE GROUPS 2/2" (there is no need to shout, incidentally).
I have not omitted anything from the start of the quoted text here -
all the context that Stephen White provided is visible.
Stephen White writes:
} [Ian Jackson writes:]
}} Stephen White writes:
>>> 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.
>
> This argument relies on your arbitrary rule being accepted as fact.
This is a very interesting comment. Unfortunately the context is
somewhat missing.
>> The second argument doesn't apply for this reason as well,
>
> And hence also relies on accepting your arbitrary rule as fact.
The `arbitrary rule' referred to is:
}} 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 I explain above, this is not an `arbitrary rule' but an
observational one.
The `two arguments' in the part of my text quoted above are that the
paragraph above fails to be true for /tmp if it has BSD semantics,
which is inconsistent, and that the setgid bit gives you clear
indication that something weird is going on - this indication being
missing when BSD semantics are used.
> Despite this, it still remains irrelevant if the group ownership is
> "fred" or "root" in the /tmp directory.
>
> [description of how the effect on people's capabilities is the same]
My arguments are not based on an incorrect effect on people's
capabilities but on the fact that BSD semantics in /tmp are less
intuitive (both compared with the rest of the filesystem under umask
022 and in general) than SysV semantics, especially seeing as the
setgid bit isn't set to flag that something odd is happening.
>> 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).
>
> Weak.
Not at all. On BSD systems the group permissions are almost always
irrelevant - why do you think BSD ls doesn't show the group ownership?
Therefore, on BSD systems the unexpected behaviour is irrelevant not
just because it doesn't make a difference to people's actual
capabilities, but because the unexpectedness affects something that
noone cares about anyway.
>>> The fact remains that uid=gid is merely a disguised BSD filing
>>> system.
>>
>> 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 am not `personally prejudiced' against the name; it is technically
inaccurate.
> I had not addressed the issue of making gid numbers equal uid numbers in
> my entire message, so your misunderstanding is difficult to comprehend.
Well, I'm sorry, but I've made precisely the opposite mistake when
responding to Remy Card - because people like you are being imprecise
in your use of terminology.
I shall now answer your argument as restated:
> ... Setgid bits on directories [are] merely a disguised BSD
> filing system.
Quite on the contrary: setgid directories are a BSD filing system made
both visible and flexible. I would say that mounting a filesystem
with BSD semantics is merely a disguised and inflexible way of getting
the effect of setgid directories.
>>> 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.
>
> Would you understand if I rephrased it to: "The one significant argument
> against..."? This is unbearably misusing the word "significant", I admit.
I didn't fail to understand it the first time. Unfortunately what you
said the first time was false as a matter of fact. Please do not try
to blame me for your inability to phrase things correctly.
What you say this time is false as a matter of opinion.
> [Matthew Hannigan wrote:]
>] 1. You can't get back the V7 semantics back for
>] individual directories.
>
> You haven't explained why this is important.
I have given one example of an area where it is useful - /tmp.
In general it is better to remain flexible. There is no good reason
for cutting off one's options here.
>> 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.
>
> I have already dealt with the fallacy of your argument of "least
> surprise".
No, you haven't. You wrote (I think this is what you're referring to,
and again I've wrapped it to fit):
>>> The principle of least surprise means that (as much as possible)
>>> you get a consistent and known result, whatever that result is and
>>> no matter where you are.
No, the principle of least surprise means exactly what it says: that
you should, where possible, try to minimise the amount of surprise.
One way of reducing surprise is to reduce the number of different
possible things that can be done - thus the outcome becomes easily
known. However, Unix has had a long history of flexibility. What one
should seek to do instead is to make the differences in behaviour as
explicit as possible in the request to and/or initial state of the
system.
Remember that the most consistent thing in general is SysV semantics
unmodified by the setgid bit: it preserves consistency between the
behaviour of uids and gids, and actually has *less* behaviour (ie, it
does less). It is better to make the request to go to a more
complicated behaviour visible - that will mean that when the behaviour
takes place the user is more likely to be expecting it.
}} The question is really which [of per-directory or per-(file)system
}} selection of group inheritance] is most likely to be required, and
}} how much effort it is to work around if one needs something
}} that's not provided.
}} ...
}}
>> 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.
>
> And here, you go against your own argument.
No, here you once again fail in reading comprehension.
I was following on from my paragraph `the question is' (which you
apparently failed to realise was relevant) by stating that
per-directory selection is more likely to be required than per-system
and/or per-filesystem selection, because the latter is unlikely to be
required at all.
>> 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.
>
> 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. [definition omitted]
Where have I used a circular argument ? A bald assertion at the end
of a lengthy debate is nowhere near sufficient to demonstrate my
alleged error.
> 2) The fallacy of sophistical refutations. ["Straw man"]
Again, it is not sufficient merely to claim that I am attacking a
straw man. You must point to the specific location of my supposed
attack on a position you do not hold, and preferably show how the
position you do hold differs from that I am attacking.
In general it would seem to me more likely that you have merely failed
to express yourself clearly - you have certainly done so on several
occasions and then attempted to lay blame on me for interpreting what
you wrote as what you meant.
> 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.
The extra `complexity' is not just complexity - it is flexibility and
visibility.
Flexibility is in general useful; don't rule out making it possible to
do something merely because it's "complicated" to specify whether to
do it or not - if the original designers of Unix had thought that way
Unix wouldn't be the programmers' refuge that it is.
Visibility is useful because it means that people are more likely to
see what is causing a particular behaviour. This allows them both to
expect the behaviour in advance and to take advantage of the
flexibility I mention above if they wish to turn it off.
--
Ian Jackson, at home <ijackson@nyx.cs.du.edu> or <iwj10@cus.cam.ac.uk>
Cambridge University Computer Laboratory, Security Group
PGP2 public key available on server. Urgent email: <iwj@cam-orl.co.uk>
Reply to: