>You're partly right. What it means is that any directories that a user
>creates underneath here are given group "staff" and not the primary
>group to which the user belongs. If the user wants the directory to have
>a different group he/she must chgrp it. This is a BSDism.
>
> [I knew this. Actually, I wasn't thinking everything through. - mcr]
>
>It is more than likely that this permission is not (strictly) set on the
>directory but instead is an option to the mount command (-o grpid). You'd
>have to check /etc/fstab.
No, the permission is strictly set on the directory.
If a directory has the set-GID bit set, then any files created in that
directory will be given, when created, the same group owner as the group
owner of the directory, regardless of whether the file system was
mounted with "grpid" or not.
If a directory has the set-GID bit cleared, then:
if the file system containing the directory was mounted with the
"grpid" option, newly-created files will be given the group
owner of the directory;
if the file system containing the directory was not mounted with
the "grpid" option, newly-created files will be given, as a
group owner, the effective group ID of the process creating
them.
If the file system is mounted with "grpid", that will *NOT* cause
directories on that file system to have their set-GID bit magically set
- i.e., the permission is strictly set on the directory.
The set-GID bit is a Sun/AT&T-ism; BSD always provides the "give it the
group owner of the directory in which it's created" behavior, but SunOS
4.x, if the file system isn't mounted with "grpid", gives it only if the
set-GID bit on the directory is set. SVR4 doesn't have "grpid", so it
gives it only if the set-GID bit on the directory is set, period.
> What I *was* thinking was that given a liberal umask like 002,
>having g+s along with +t would mean that anyone in group staff could
>clean up.
Eh? The write permission on the underlying *file* doesn't affect whether
it can be deleted, it just affects whether the "rm" command will ask you
whether you should remove it or not. It's the group write bit on the
*directory* that governs whether people in the "staff" group can delete
things from that directory or not; the set-GID bit on the directory has
no effect on that, one way or the other.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:55 CDT