NetBSD Problem Report #38102

From Wolfgang.Stukenbrock@nagler-company.com  Mon Feb 25 13:52:29 2008
Return-Path: <Wolfgang.Stukenbrock@nagler-company.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 9C95D63B853
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 25 Feb 2008 13:52:29 +0000 (UTC)
Message-Id: <20080225135226.EFBC35FB649@s010.nagler-company.com>
Date: Mon, 25 Feb 2008 14:52:26 +0100 (CET)
From: Wolfgang.Stukenbrock@nagler-company.com
Reply-To: Wolfgang.Stukenbrock@nagler-company.com
To: gnats-bugs@gnats.NetBSD.org
Subject: NetBSD NFS-Fileserver will break s-bit-Semantik on directories for NFS-Clients
X-Send-Pr-Version: 3.95

>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:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.