PRIVATE GROUPS 1/2
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.
But, since you insist, I shall endeavour to explain my apparently
incomprehensible utterings.
IJ> False. Quite a lot of activity happens in /tmp and /usr/tmp,
IJ> on my system at least.
SW> This is a non-argument. It is completely irrelevant to the issue.
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.
IJ> You claimed that all the action occurs in directories which would
IJ> be setgid, and implied that only project and user home
IJ> directories would be.
IJ>
IJ> Your claim was false, so the argument you based on it was unsound.
Incorrect. Your understanding of my argument is severely flawed.
Therefore, your refutations are unsound. Poetic, isn't it?
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.
SW> With the setgid scheme, virtually all activity will be conducted
SW> under BSD semantics anyway.
This statement remains true. Or perhaps did you envision users frolicing
in the fairyland of /etc with SysV semantics? Perhaps a little day trip
over to /sbin with SysV semantics to recover from the drudge of labouring
under BSD semantics? Dearie me.
SW> Why is there a ... requirement to have SysV semantics within /tmp
SW> 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.
Onto your main defence:
IJ> Now, in general, if we adopt the private groups scheme the most
IJ> important part of the ownership of a file will no longer be the
IJ> user ownership but the group ownership,
IJ> My first argument in this message against BSD semantics in /tmp
IJ> 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.
IJ> My second argument in this message against BSD semantics is that
IJ> it is generally less expected than System V semantics.
About as unexpected as setgid bits on directories, Ian.
IJ> When using SysV semantics the setgid bit gives you a clear
IJ> indication that something is happening to the group ownerships
It is only clear if you look, and know about setgid.
IJ> When using BSD semantics this will be less clear, and the
IJ> behaviour will therefore be further from that which might be
IJ> expected.
You are advocating a mix of SysV and BSD and claiming it will have a more
expected behaviour?
To find out the group ownership of a created file under setgid:
1) ls -ld ..
2) Check the setgid bit.
3) If it is set, then the group of the created file is the same as
the group of the directory.
4) Otherwise, the group of the created file is the same as the group of
the creator.
Under BSD mount, it is simply:
1) The group of the created file is always the same as the group of the
directory.
Which looks more like conforming to "least surprise", Ian?
Reply to: