[LU-12922] pjdfstest chown_00: POSIX compliance failed on lustre

• Status: Open
• Project: Lustre
• Affects Version/s: Lustre 2.13.0
• Type: Bug
• Priority: Minor
• Reporter: Maloo
• Assignee: WC Triage
• Resolution: Unresolved
• Severity: 3

Description

This issue was created by maloo for sarah <[e-mail]>

This issue relates to the following test suite run: https://testing.whamcloud.com/test_sets/661f272e-fb43-11e9-a0ba-52540065bddc

test_2 failed with the following error:

PJDFSTEST against lustre failed

The new added pjdfstest failed against lustre on different tests, here is the summary

Test Summary Report
-------------------
/usr/share/pjdfstest/chmod/00.t          (Wstat: 0 Tests: 119 Failed: 4)
  Failed tests:  112-114, 116
/usr/share/pjdfstest/chmod/07.t          (Wstat: 0 Tests: 25 Failed: 2)
  Failed tests:  7, 17
/usr/share/pjdfstest/chown/00.t          (Wstat: 0 Tests: 1323 Failed: 37)
  Failed tests:  292, 299, 307, 312, 319, 327, 332, 339
                347, 352, 359, 367, 372, 379, 387, 392
                399, 407, 412, 954-956, 978-980, 1002-1004
                1026-1028, 1050-1052, 1074-1076
/usr/share/pjdfstest/chown/07.t          (Wstat: 0 Tests: 132 Failed: 38)
  Failed tests:  7-8, 12-13, 20-21, 27-28, 32-33, 40-41
                47-48, 52-53, 60-61, 67-68, 72-73, 80-81
                87-88, 92-93, 100-101, 107-108, 112-113
                120-121, 127-128
/usr/share/pjdfstest/mkdir/00.t          (Wstat: 0 Tests: 36 Failed: 6)
  Failed tests:  18-23
/usr/share/pjdfstest/mkfifo/00.t         (Wstat: 0 Tests: 36 Failed: 6)
  Failed tests:  18-23
/usr/share/pjdfstest/mknod/00.t          (Wstat: 0 Tests: 36 Failed: 6)
  Failed tests:  18-23
/usr/share/pjdfstest/open/00.t           (Wstat: 0 Tests: 47 Failed: 6)
  Failed tests:  18-23
/usr/share/pjdfstest/open/06.t           (Wstat: 0 Tests: 144 Failed: 20)
  Failed tests:  9-11, 13-15, 21, 25, 34, 38, 70-71, 73-74
                80, 84, 116, 118, 122, 124
/usr/share/pjdfstest/rename/10.t         (Wstat: 0 Tests: 2099 Failed: 6)
  Failed tests:  2062, 2091-2095
/usr/share/pjdfstest/utimensat/08.t      (Wstat: 0 Tests: 9 Failed: 2)
  Failed tests:  5-6
Files=232, Tests=8789, 212 wallclock secs ( 1.29 usr  0.22 sys + 27.94 cusr 38.87 csys = 68.32 CPU)
Result: FAIL

VVVVVVV DO NOT REMOVE LINES BELOW, Added by Maloo for auto-association VVVVVVV
pjdfstest test_2 - PJDFSTEST against lustre failed

Issue Links

• is related to: LU-1158 nanosecond timestamp support for Lustre
• is related to: LU-12662 Run pjdfstest POSIX test in review an...

Comments

[Andreas Dilger]

It looks like a number of failures are duplicated between ext4 and lustre and should be excluded from the testing, so that the ext4 test passes.

There are a large number of tests that are failing with expected 0, got EACCES, which at first glance may relate to the test using supplementary groups that are not configured on the MDS. It makes sense to either configure the test to use groups that are already existing, or the groups have to be added on the MDS.

I think once these failures have been addressed, there will be only a small number of remaining failures that need to be looked at.

[Sarah Liu]

After adding the required user/group ID, this test failed on 2 subtests against Lustre
https://testing.whamcloud.com/test_sets/f7bb158c-47e3-4b29-96c6-146b42120003

== pjdfstest test 3a: chown changes ownership (chown/00.t) =========================================== 19:54:08 (1582574048)
Run /usr/share/pjdfstest/chown/00.t against ext4 filesystem
prove -f /usr/share/pjdfstest/chown/00.t > /tmp/pjdfstest-ext4 2>&1
Run /usr/share/pjdfstest/chown/00.t against lustre filesystem
prove -f /usr/share/pjdfstest/chown/00.t > /tmp/pjdfstest-lustre 2>&1
ext4 report
/usr/share/pjdfstest/chown/00.t .. ok
All tests successful.
Files=1, Tests=1323, 81 wallclock secs ( 0.18 usr  0.01 sys +  2.17 cusr  5.02 csys =  7.38 CPU)
Result: PASS
lustre report
/usr/share/pjdfstest/chown/00.t .. 
not ok 312 - tried '-u 65532 -g 65531 -- chown pjdfstest_c2eeb5584dbe39810035c7d5745e8702 -1 -1', expected 0, got EPERM
not ok 319 - tried '-u 65532 -g 65531 -- chown pjdfstest_c2eeb5584dbe39810035c7d5745e8702 -1 -1', expected 0, got EPERM
not ok 327 - tried '-u 65532 -g 65531 -- lchown pjdfstest_c2eeb5584dbe39810035c7d5745e8702 -1 -1', expected 0, got EPERM
Failed 3/1323 subtests 

== pjdfstest test 17i: utimensat can set timestamps with subsecond precision (utimensat/08.t) ======== 20:20:17 (1582575617)
Run /usr/share/pjdfstest/utimensat/08.t against ext4 filesystem
prove -f /usr/share/pjdfstest/utimensat/08.t > /tmp/pjdfstest-ext4 2>&1
Run /usr/share/pjdfstest/utimensat/08.t against lustre filesystem
prove -f /usr/share/pjdfstest/utimensat/08.t > /tmp/pjdfstest-lustre 2>&1
ext4 report
/usr/share/pjdfstest/utimensat/08.t .. 
not ok 5 - tried 'lstat pjdfstest_0ae536f2c253c944c4d725e3a6b60c95 atime_ns', expected 100000000, got 0
not ok 6 - tried 'lstat pjdfstest_0ae536f2c253c944c4d725e3a6b60c95 mtime_ns', expected 200000000, got 0
Failed 2/9 subtests 

[Andreas Dilger]

Lustre doesn't store nanosecond timestamps (at least not until LU-1158 is updated and landed), but I don't think that is a priority for anyone at this point. So those tests will not pass on Lustre and this is expected.

[James Nunez (Inactive)]

There's just three more chown failures when trying to set the user/group to -1; https://testing.whamcloud.com/test_sets/73aa184a-71a0-4f84-80c9-2182256a50ba.

lustre report
/usr/share/pjdfstest/chown/00.t .. 
not ok 312 - tried '-u 65532 -g 65531 -- chown pjdfstest_8c15b69e4c4c1ba0a36eca9dd7ada25f -1 -1', expected 0, got EPERM
not ok 319 - tried '-u 65532 -g 65531 -- chown pjdfstest_8c15b69e4c4c1ba0a36eca9dd7ada25f -1 -1', expected 0, got EPERM
not ok 327 - tried '-u 65532 -g 65531 -- lchown pjdfstest_8c15b69e4c4c1ba0a36eca9dd7ada25f -1 -1', expected 0, got EPERM
Failed 3/1323 subtests 

I"m having a hard time finding a copy of the POSIX standard that is freely accessible, but from chown(2), I see the following:
If the owner or group is specified as -1, then that ID is not changed.

[Andreas Dilger]

I usually reference The Single UNIX Specification v2 for this kind of information, it says in the chown(2) section:

Changing the group ID is permitted to a process with an effective user ID equal to the user ID of the file, but without appropriate privileges, if and only if owner is equal to the file's user ID or (uid_t)-1 and group is equal either to the calling process' effective group ID or to one of its supplementary group IDs.

If owner or group is specified as (uid_t)-1 or (gid_t)-1 respectively, the corresponding ID of the file is unchanged.
ERRORS
[EPERM]
The effective user ID does not match the owner of the file, or the calling process does not have appropriate privileges.

Presumably these errors do not appera for ext4 or XFS?

[James Nunez (Inactive)]

Correct, looking at the latest test results, we do not see the chown -1 owner/user issue for ext4. All tests in chown/00.t pass.