[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/38102: NetBSD NFS-Fileserver will break s-bit-Semantik on directories for NFS-Clients
>Synopsis: NetBSD NFS-Fileserver will break s-bit-Semantik on directories
>Arrival-Date: Mon Feb 25 13:55:00 +0000 2008
>Originator: Wolfgang Stukenbrock
>Release: NetBSD 4.0
Dr. Nagler & Company GmbH
System: NetBSD s010 4.0 NetBSD 4.0 (NSW-S010) #16: Wed Feb 20 12:51:34 CET 2008
On NetBSD any filesystem object created will have the group of the
directory, regardless of the groups
of the caller. But some systems - e.g. Sun Clients - have a more
complex view to this point.
The group of a created filesystem object will be the primary group of
the caller if no group-sbit is set
on the directory where the new object is created. if the group-sbit is
set, than the same semantic is used
as NetBSD does in any case.
I don't whant to start a discussion what semantic will be better, but
if a NetBSD file server exports
a filesystem to a Sun-Client, than both semantics gets mixed up and
make it impossible to share access of
some users to the filesystem, if not the primary group of all users is
If accessed on the server or from another NetBSD client, all created
objects will have the group of the
If a filesystem object is created from the Sun-client, the object gets
the primary group of user who
creates it, because the Sun-client will issue a chgrp if the group of
the new object does not have the
Now trying to fix this bey setting the group s-bit on the parent
directory, will solve this problem for
one level of directories. All objects in this directory will get the
group of the parent directory regardless
of the type of client that will create it.
But if a directory is created, the s-bit is lost on the new directory,
and so the "old" problem came up
for that one again.
Don't ask me why the Sun will change the group id in one case, but will
ignore the missing s-bit on the
created directory. Even if the Sun would set it again that won't help,
because if a directory is created
on the server itself or a NetBSD client, the directory would again
loose the s-bit.
The best way to fix this problem, is to cary the group s-bit on the
directory to a new created directory.
If this will be done, Sun-clients are happy and the NetBSD semantics
are not affected by this.
Export a filesystem to a Sun NFS-Client and create some nested
Directories and Files and
see that the s-Bit on the directory, that is needed for the Sun-client
is lost and filesystem
objects in the created Subdirectory are created with the wrong group.
The following patch to /usr/src/sys/ufs/ufs/ufs_vnops.c will solve the
If a directory has a group s-bit, than any directory created inside of
it will also have the s-bit set.
--- ufs_vnops.c 2008/02/14 13:46:29 1.1
+++ ufs_vnops.c 2008/02/14 15:07:01
@@ -1268,7 +1268,17 @@
dmode = vap->va_mode & ACCESSPERMS;
- dmode |= IFDIR;
+ * remark: keep group s-bit from parent directory for NFS-clients that
will need it ...
+ * accedently we cannot trust our caller - e.g. NetBSD it self
will not pass
+ * the s-bit set ...
+ * We assume that the dinode part is present.
+ * This seems to be true for all cases, because there seems to
be no code called
+ * to read something in in front of the assignment
"DIP_ASSIGN(dp, nlink, dp->i_nlink)"
+ * below.
+ dmode |= IFDIR | (DIP(dp, mode) & S_ISGID);
* Must simulate part of ufs_makeinode here to acquire the inode,
* but not have it entered in the parent directory. The entry is
Main Index |
Thread Index |