kern/38102: NetBSD NFS-Fileserver will break s-bit-Semantik on directories for NFS-Clients

[Wolfgang.Stukenbrock%nagler-company.com@localhost]

>Number:         38102
>Category:       kern
>Synopsis:       NetBSD NFS-Fileserver will break s-bit-Semantik on directories 
>for NFS-Clients
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 25 13:55:00 +0000 2008
>Originator:     Wolfgang Stukenbrock
>Release:        NetBSD 4.0
>Organization:
Dr. Nagler & Company GmbH
        
>Environment:
        
        
System: NetBSD s010 4.0 NetBSD 4.0 (NSW-S010) #16: Wed Feb 20 12:51:34 CET 2008 
wgstuken@s012:/export/NetBSD-4.0/N+C-build/.OBJDIR_amd64/export/NetBSD-4.0/src/sys/arch/amd64/compile/NSW-S010
 amd64
Architecture: x86_64
Machine: amd64
>Description:
        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 
the saem.

        If accessed on the server or from another NetBSD client, all created 
objects will have the group of the
        parent direcotry.
        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
        expected group.
        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.
>How-To-Repeat:
        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.
>Fix:
        The following patch to /usr/src/sys/ufs/ufs/ufs_vnops.c will solve the 
problem.
        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 @@
                goto out;
        }
        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

>Unformatted: