On Thu, 29 Oct 2009 casper....@sun.com wrote: > Do you have the complete NFS trace output? My reading of the source code > says that the file will be created with the proper gid so I am actually > believing that the client "over corrects" the attributes after creating > the file/directory.
I dug around the OpenSolaris source code and believe I found where this behavior is coming from. In http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs4_srv.c on line 1643, there's a comment: "Set default initial values for attributes when not specified in createattrs." And if the uid/gid is not explicitly specified in the NFS CREATE operation, the code calls crgetuid and crgetgid to determine what uid/gid to use for the mkdir operation. crgetgid is just "return (cr->cr_gid);", which would result in the behavior we describe -- if there is no group owner explicitly specified, new subdirectories are always created based on the primary group of the user, disregarding the presence of any sgid bit on the parent directory. As far as the client: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs4_vnops.c On line 6790 the client code explicitly checks whether or not the new directory is being created inside of a parent directory with a sgid bit set, and then explicitly includes the group owner if so. I'm guessing you are probably looking at the actual underlying filesystem code? That probably does do the right thing if the gid is not specified. But given the NFS server code, if no gid is specified by the client, explicitly uses the primary gid, by the time it gets to the underlying file system the gid is already specified and any filesystem level sgid handling is bypassed. I doubt if the resolution to the problem is as simple as not having the NFS server code explicitly specify a gid if none is given by the client, allowing the underlying filesystem to "do the right thing", but who knows :)... I still think that the preferred behavior would be to respect the sgid bit semantics, and continue to hope I can convince the engineers in charge of this decision to agree. Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
