From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 9C4F37F5A for ; Thu, 5 Sep 2013 09:41:10 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 83D1A304067 for ; Thu, 5 Sep 2013 07:41:10 -0700 (PDT) Received: from sandeen.net (sandeen.net [63.231.237.45]) by cuda.sgi.com with ESMTP id k3qCMnhBNTDlgxYr for ; Thu, 05 Sep 2013 07:41:09 -0700 (PDT) Message-ID: <52289805.5040302@sandeen.net> Date: Thu, 05 Sep 2013 09:41:09 -0500 From: Eric Sandeen MIME-Version: 1.0 Subject: Re: SGID inheritance in different file-systems References: <52208DC0.2030805@oracle.com> <52289569.1070107@sandeen.net> <5228963B.9010404@oracle.com> In-Reply-To: <5228963B.9010404@oracle.com> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Vasily Isaenko Cc: xfs@oss.sgi.com On 9/5/13 9:33 AM, Vasily Isaenko wrote: > Hi Eric, > = > On 09/05/2013 06:30 PM, Eric Sandeen wrote: >> On 8/30/13 7:19 AM, Vasily Isaenko wrote: >>> Dear XFS Members, >>> >>> In the XFS test suite there is a test case generic/314 "Test SGID inher= itance on subdirectories". >>> It is not specific to a particular filesystem thus selected for both xf= s or ext4 test runs. >>> In other words, the same behaviour is expected and enforced for XFS and= EXT4. >> Yep, and it passes on both of them, as well as on ext3, ext2, btrfs, and= gfs2... >> >>> However, I have been told that EXT4 and XFS may have different behaviou= r as the >>> setgid-directory behavior is not guaranteed to work the same way on all= filesystems. >> "I have been told" ... I'm guessing that you have tested a filesystem wh= ich doesn't >> behave this way? Which one? > = > yes, the generic/314 test has failed on xfs while passed on ext4 though. > = > if this is intentional behaviour on xfs it is fine, but would it be possi= ble to > make this test skipped on xfs then? no... When a test fails, you don't just turn it off; you figure out why it failed. Indeed, this test was written _because_ xfs failed, was fixed, and the test serves as a regression test to be sure it doesn't ever fail again. If you're testing an older kernel, presumably it doesn't have the fix. If you're testing a newer kernel, something else is wrong, because it passes for me just fine on xfs, upstream. Thanks, -Eric > Thank you, > Vasily > = >> >>> Shall XFS test case reflect that difference or enforcing the same behav= iour is appropriate? >> If you have information that a filesystem exists which does not inherit = SGID, and >> that this behavior is intentional and correct and standards-compliant, t= hen feel >> free to submit a patch. >> >> However, I think you'll need to have a convincing argument against the m= an pages. >> >> chmod(2) says: >> >> S_ISGID (02000) set-group-ID (set process effective gr= oup ID on >> execve(2); mandatory locking, as described in= fcntl(2); >> take a new file=92s group from parent d= irectory, as >> described in chown(2) and mkdir(2)) >> >> mkdir(2) says: >> >> The newly created directory will be owned by the effective user = ID of the >> process. If the directory containing the file has the set-g= roup-ID bit >> set, or if the file system is mounted with BSD group semantics = (mount -o >> bsdgroups or, synonymously mount -o grpid), the new directory w= ill inherit >> the group ownership from its parent; otherwise it will be own= ed by the >> effective group ID of the process. >> >> and chown(2) says: >> >> NOTES >> When a new file is created (by, for example, open(2) or mkd= ir(2)), its >> owner is made the same as the file system user ID of the creatin= g process. >> The group of the file depends on a range of factors, including = the type of >> file system, the options used to mount the file system, and whet= her or not >> the set-group-ID permission bit is enabled on the parent directo= ry. If the >> file system supports the -o grpid (or, synonymously -o bsdg= roups) and >> -o nogrpid (or, synonymously -o sysvgroups) mount(8) option= s, then the >> rules are as follows: >> >> * If the file system is mounted with -o grpid, then the group of= a new file >> is made the same as that of the parent directory. >> >> * If the file system is mounted with -o nogrpid and the set-grou= p-ID bit is >> disabled on the parent directory, then the group of a new fil= e is made >> the same as the process=92s file system GID. >> >> * If the file system is mounted with -o nogrpid and the set-grou= p-ID bit is >> enabled on the parent directory, then the group of a new file = is made the >> same as that of the parent directory. >> >> Thanks, >> Eric >> >>> Best regards, >>> Vasily >>> >>> _______________________________________________ >>> xfs mailing list >>> xfs@oss.sgi.com >>> http://oss.sgi.com/mailman/listinfo/xfs >>> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs > = _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs