Ian Jackson writes:
> 4. It violates the principle of least surprise.
I disagree with this statement. 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.
A filing system with setgid directories would be a strange one to navigate. "cd
/", and we're in SysV. "cd /usr/src" and we're in BSD. "cd /usr/spool" and
we're in SysV again.
To find out what semantics were in operation in any particular directory, you'd
have to do "ls -l .." and then look for the directory you're in. Imagine the
effect on programs. How many do you know that have been written to cope with
mixed filing systems?
Using setgid bits on directories means that the ownership of created files will
vary depending on whatever directory you're in. Same actions, different
results. This does not comply with the principle of least surprise.
So, what exactly are the setgid's being used for? Answer; to create BSD
semantics for selected directories, those being the user directories and
And those directories is where all the action occurs. With the setgid scheme,
virtually all activity will be conducted under BSD semantics anyway.
Why bother with a weird system of permissions? Why bother with the added
complexity? It's so much easier to just mount the drive with bsd semantics,
wack in an additional line in the "adduser" script, and be done with it. Two
small changes. Simple.
The argument basically comes to this point; "Do you want to implement the
scheme, or do you want to keep SysV semantics?". Using the setgid scheme is
merely implementing a disguised BSD filing system.
I prefer to implement the scheme and mount with BSD semantics.