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:33:31 +0400	[thread overview]
Message-ID: <5228963B.9010404@oracle.com> (raw)
In-Reply-To: <52289569.1070107@sandeen.net>

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@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:35 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 [this message]
2013-09-05 14:41     ` Eric Sandeen
2013-09-05 14:42       ` Vasily Isaenko

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=5228963B.9010404@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