public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Vasily Isaenko <vasily.isaenko@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: SGID inheritance in different file-systems
Date: Thu, 05 Sep 2013 18:42:27 +0400	[thread overview]
Message-ID: <52289853.7010907@oracle.com> (raw)
In-Reply-To: <52289805.5040302@sandeen.net>

Thank you Eric and Carlos for your responses!


On 09/05/2013 06:41 PM, Eric Sandeen wrote:
> 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 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?
> 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 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@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

      reply	other threads:[~2013-09-05 14:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30 12:19 SGID inheritance in different file-systems Vasily Isaenko
2013-09-05 14:30 ` Eric Sandeen
2013-09-05 14:33   ` Vasily Isaenko
2013-09-05 14:41     ` Eric Sandeen
2013-09-05 14:42       ` Vasily Isaenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52289853.7010907@oracle.com \
    --to=vasily.isaenko@oracle.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox