* SGID inheritance in different file-systems @ 2013-08-30 12:19 Vasily Isaenko 2013-09-05 14:30 ` Eric Sandeen 0 siblings, 1 reply; 5+ messages in thread From: Vasily Isaenko @ 2013-08-30 12:19 UTC (permalink / raw) To: xfs 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. 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. Shall XFS test case reflect that difference or enforcing the same behaviour is appropriate? Best regards, Vasily _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SGID inheritance in different file-systems 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 0 siblings, 1 reply; 5+ messages in thread From: Eric Sandeen @ 2013-09-05 14:30 UTC (permalink / raw) To: Vasily Isaenko; +Cc: xfs 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? > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SGID inheritance in different file-systems 2013-09-05 14:30 ` Eric Sandeen @ 2013-09-05 14:33 ` Vasily Isaenko 2013-09-05 14:41 ` Eric Sandeen 0 siblings, 1 reply; 5+ messages in thread From: Vasily Isaenko @ 2013-09-05 14:33 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SGID inheritance in different file-systems 2013-09-05 14:33 ` Vasily Isaenko @ 2013-09-05 14:41 ` Eric Sandeen 2013-09-05 14:42 ` Vasily Isaenko 0 siblings, 1 reply; 5+ messages in thread From: Eric Sandeen @ 2013-09-05 14:41 UTC (permalink / raw) To: Vasily Isaenko; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: SGID inheritance in different file-systems 2013-09-05 14:41 ` Eric Sandeen @ 2013-09-05 14:42 ` Vasily Isaenko 0 siblings, 0 replies; 5+ messages in thread From: Vasily Isaenko @ 2013-09-05 14:42 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-09-05 14:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox