xfs
[Top] [All Lists]

Re: SGID inheritance in different file-systems

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: SGID inheritance in different file-systems
From: Vasily Isaenko <vasily.isaenko@xxxxxxxxxx>
Date: Thu, 05 Sep 2013 18:33:31 +0400
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <52289569.1070107@xxxxxxxxxxx>
References: <52208DC0.2030805@xxxxxxxxxx> <52289569.1070107@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
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 inheritance on 
subdirectories".
It is not specific to a particular filesystem thus selected for both xfs 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 behaviour 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 which 
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 possible to
make this test skipped on xfs then?

Thank you,
Vasily


Shall XFS test case reflect that difference or enforcing the same behaviour 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, then feel
free to submit a patch.

However, I think you'll need to have a convincing argument against the man 
pages.

chmod(2) says:

        S_ISGID  (02000)  set-group-ID   (set   process   effective   group  ID 
 on
                          execve(2); mandatory locking, as described  in  
fcntl(2);
                          take  a  new  file’s  group  from  parent  directory, 
 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-group-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 will 
inherit
        the group ownership from its parent; otherwise it  will  be  owned  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 mkdir(2)), 
its
        owner is made the same as the file system user ID of the creating  
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 whether or  
not
        the set-group-ID permission bit is enabled on the parent directory.  If 
the
        file system supports  the  -o grpid  (or,  synonymously  -o bsdgroups)  
and
        -o nogrpid  (or,  synonymously  -o sysvgroups)  mount(8)  options, 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-group-ID 
bit is
          disabled on the parent directory, then the group of a new  file  is  
made
          the same as the process’s file system GID.

        * If the file system is mounted with -o nogrpid and the set-group-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@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs

<Prev in Thread] Current Thread [Next in Thread>