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@xxxxxxxxxxx >>> http://oss.sgi.com/mailman/listinfo/xfs >>> >> _______________________________________________ >> xfs mailing list >> xfs@xxxxxxxxxxx >> http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
