Clifford Wolf wrote:
> But that only makes sense if the umask is set to give full permissions to
> the group (e.g. 007 or 002). Noone would do that if there is a system-wide
> 'users' group - so some distributions add an extra group for every user
> which lets the /etc/group file grow very fast and makes the admins life
> harder ...
Concured. In my experience, "extra group for every user" doesn't work
with you're sharing over NFS with systems that don't use it. Which
means using a umask of 022 or 077, and that renders the SGID-directory
feature almost useless.
I've seen two problems result from this: user files created group
writable on the NFS server, when they should not be (a security
problem). And shared directories created non-group-writable, which
other group members cannot fix. (Only root can fix this).
For example where I work, some of the CVS directories cannot be checked
out because some directories, which should be group writable, are not.
> The following small patch adds a function to the SUID flag on directories.
> If the SUID flag is set for a diectory, all new files in that directory
> will get the same rights in the group-field as they have in their
> user-field.
Your patch does not fix the problem with CVS directories. In those,
directories need to be writable, but newly created user files should not
necessarily be group writable.
So I would suggest this behaviour:
sgid directory -> new subdirectories copy group umask from user umask
suid directory -> new non-directories copy group umask from user umask
Both these behaviours would be enabled by a mount option, preferably a
generic one.
cheers,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:28 EST