Bug 1223782

Summary: nfs-ganesha: posix test failure with vers=3, for chown and link tests
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Saurabh <saujain>
Component: nfs-ganeshaAssignee: Soumya Koduri <skoduri>
Status: CLOSED CURRENTRELEASE QA Contact: Saurabh <saujain>
Severity: high Docs Contact:
Priority: high    
Version: rhgs-3.1CC: annair, ansubram, asrivast, kkeithle, mmadhusu, mzywusko, ndevos, nlevinki, skoduri
Target Milestone: ---   
Target Release: RHGS 3.1.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-07 12:54:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Saurabh 2015-05-21 12:46:46 UTC 
Description of problem:
With nfs-ganeha being mounted with vers=3, I have found these failure with posix test suite,

Test Summary Report
-------------------
/opt/qa/tools/pjd-fstest-20080816/tests/chown/00.t   (Wstat: 0 Tests: 170 Failed: 2)
  Failed tests:  83, 87
/opt/qa/tools/pjd-fstest-20080816/tests/link/00.t    (Wstat: 0 Tests: 80 Failed: 2)
  Failed tests:  72, 76
Files=184, Tests=1954, 140 wallclock secs ( 1.30 usr  0.53 sys +  9.63 cusr 11.61 csys = 23.07 CPU)
Result: FAIL

Version-Release number of selected component (if applicable):
glusterfs-3.7.0-2.el6rhs.x86_64
nfs-ganesha-2.2.0-0.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. create a volume of type 6x2, start it
2. bring up nfs-ganesha, after completing the pre-requisites
3. execute the posix testsuite. post mounting the volume with vers=3

Actual results:
as mentioned in description section

Expected results:
posix test suite should be a pass

Additional info:
Comment 3 Soumya Koduri 2015-06-09 12:42:15 UTC 
I have tested it using latest sources. As updated in the bug , there are only two test failures seen - 

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
v3 Mount- 

Test Summary Report
-------------------
/opt/qa/tools/posix-testsuite/tests/chown/00.t   (Wstat: 0 Tests: 171 Failed: 1)
  Failed test:  77
Files=185, Tests=1962, 104 wallclock secs ( 0.64 usr  0.20 sys +  3.04 cusr  0.56 csys =  4.44 CPU)
Result: FAIL



v4 Mount - 

Test Summary Report
-------------------
/opt/qa/tools/posix-testsuite/tests/chown/00.t   (Wstat: 0 Tests: 171 Failed: 1)
  Failed test:  77
/opt/qa/tools/posix-testsuite/tests/open/07.t    (Wstat: 0 Tests: 23 Failed: 3)
  Failed tests:  5, 7, 9
Files=185, Tests=1962, 106 wallclock secs ( 0.67 usr  0.17 sys +  3.06 cusr  0.57 csys =  4.47 CPU)
Result: FAIL

With respect to chown tests, I see the same failure in case of Gluster-NFS as well.
/opt/qa/tools/posix-testsuite/tests/chown/00.t
Failed test:  77

<<<<<<<
# when non-super-user calls chown(2) successfully, set-uid and set-gid bits are
# removed, except when both uid and gid are equal to -1.
# 64
expect 0 create ${n0} 0644
expect 0 chown ${n0} 65534 65533
expect 0 chmod ${n0} 06555
expect 06555 lstat ${n0} mode
expect 0 -u 65534 -g 65533,65532 chown ${n0} 65534 65532
expect 0555,65534,65532 lstat ${n0} mode,uid,gid
expect 0 chmod ${n0} 06555
expect 06555 lstat ${n0} mode
expect 0 -u 65534 -g 65533,65532 -- chown ${n0} -1 65533
expect 0555,65534,65533 lstat ${n0} mode,uid,gid
expect 0 chmod ${n0} 06555
expect 06555 lstat ${n0} mode
expect 0 -u 65534 -g 65533,65532 -- chown ${n0} -1 -1
case "${os}" in
Linux)
echo "os = ${os}"
	expect 0555,65534,65533 lstat ${n0} mode,uid,gid
        ;;
*)
	expect 06555,65534,65533 lstat ${n0} mode,uid,gid
        ;;
esac
>>>>>>>>

Last 'expect' in this block is test#77. From the packet trace I have observed that nfs-client never sends 'expect 0 -u 65534 -g 65533,65532 -- chown ${n0} -1 -1' to the server and that has resulted in no change in the mode-bits. This doesn't seem a server issue.


/opt/qa/tools/posix-testsuite/tests/open/07.t    (Wstat: 0 Tests: 23 Failed: 3)
  Failed tests:  5, 7, 9


These are the expected failures with respect to NFSv4. Got same results using kernel-NFS as well. 


expect 0 -u 65534 -g 65534 create ${n1} 0644

expect 0 -u 65534 -g 65534 chmod ${n1} 0477
expect EACCES -u 65534 -g 65534 open ${n1} O_RDONLY,O_TRUNC   (FAIL)
expect 0 -u 65534 -g 65534 chmod ${n1} 0747
expect EACCES -u 65533 -g 65534 open ${n1} O_RDONLY,O_TRUNC   (FAIL)
expect 0 -u 65534 -g 65534 chmod ${n1} 0774
expect EACCES -u 65533 -g 65533 open ${n1} O_RDONLY,O_TRUNC   (FAIL)

The issue here is that in the test it tries to open the file in O_READ, O_TRUNC mode which should ideally have returned EACCESS. But NFSv4 client maps it to OPEN with 'OPEN4_SHARE_ACCESS_READ' and since the owner has READ permissions, server rightly grants it.

That means both chown(00.t - #77) and open(07.t - #5, #7, #9) tests should be marked as Known_Issues.


$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

As both these failures are expected, these tests should be ignored. Marking
this bug as ON_QA. Please re-open if there are any failures reported. Also, please cross-check the behaviour with kNFS as well. Thanks!
Comment 4 Saurabh 2015-07-07 12:54:14 UTC 
(In reply to Soumya Koduri from comment #3)
> I have tested it using latest sources. As updated in the bug , there are
> only two test failures seen - 
> 
> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$
> v3 Mount- 
> 
> Test Summary Report
> -------------------
> /opt/qa/tools/posix-testsuite/tests/chown/00.t   (Wstat: 0 Tests: 171
> Failed: 1)
>   Failed test:  77
> Files=185, Tests=1962, 104 wallclock secs ( 0.64 usr  0.20 sys +  3.04 cusr 
> 0.56 csys =  4.44 CPU)
> Result: FAIL
> 
> 
> 
> v4 Mount - 
> 
> Test Summary Report
> -------------------
> /opt/qa/tools/posix-testsuite/tests/chown/00.t   (Wstat: 0 Tests: 171
> Failed: 1)
>   Failed test:  77
> /opt/qa/tools/posix-testsuite/tests/open/07.t    (Wstat: 0 Tests: 23 Failed:
> 3)
>   Failed tests:  5, 7, 9
> Files=185, Tests=1962, 106 wallclock secs ( 0.67 usr  0.17 sys +  3.06 cusr 
> 0.57 csys =  4.47 CPU)
> Result: FAIL
> 
> With respect to chown tests, I see the same failure in case of Gluster-NFS
> as well.
> /opt/qa/tools/posix-testsuite/tests/chown/00.t
> Failed test:  77
> 
> <<<<<<<
> # when non-super-user calls chown(2) successfully, set-uid and set-gid bits
> are
> # removed, except when both uid and gid are equal to -1.
> # 64
> expect 0 create ${n0} 0644
> expect 0 chown ${n0} 65534 65533
> expect 0 chmod ${n0} 06555
> expect 06555 lstat ${n0} mode
> expect 0 -u 65534 -g 65533,65532 chown ${n0} 65534 65532
> expect 0555,65534,65532 lstat ${n0} mode,uid,gid
> expect 0 chmod ${n0} 06555
> expect 06555 lstat ${n0} mode
> expect 0 -u 65534 -g 65533,65532 -- chown ${n0} -1 65533
> expect 0555,65534,65533 lstat ${n0} mode,uid,gid
> expect 0 chmod ${n0} 06555
> expect 06555 lstat ${n0} mode
> expect 0 -u 65534 -g 65533,65532 -- chown ${n0} -1 -1
> case "${os}" in
> Linux)
> echo "os = ${os}"
> 	expect 0555,65534,65533 lstat ${n0} mode,uid,gid
>         ;;
> *)
> 	expect 06555,65534,65533 lstat ${n0} mode,uid,gid
>         ;;
> esac
> >>>>>>>>
> 
> Last 'expect' in this block is test#77. From the packet trace I have
> observed that nfs-client never sends 'expect 0 -u 65534 -g 65533,65532 --
> chown ${n0} -1 -1' to the server and that has resulted in no change in the
> mode-bits. This doesn't seem a server issue.
> 
> 
> /opt/qa/tools/posix-testsuite/tests/open/07.t    (Wstat: 0 Tests: 23 Failed:
> 3)
>   Failed tests:  5, 7, 9
> 
> 
> These are the expected failures with respect to NFSv4. Got same results
> using kernel-NFS as well. 
> 
> 
> expect 0 -u 65534 -g 65534 create ${n1} 0644
> 
> expect 0 -u 65534 -g 65534 chmod ${n1} 0477
> expect EACCES -u 65534 -g 65534 open ${n1} O_RDONLY,O_TRUNC   (FAIL)
> expect 0 -u 65534 -g 65534 chmod ${n1} 0747
> expect EACCES -u 65533 -g 65534 open ${n1} O_RDONLY,O_TRUNC   (FAIL)
> expect 0 -u 65534 -g 65534 chmod ${n1} 0774
> expect EACCES -u 65533 -g 65533 open ${n1} O_RDONLY,O_TRUNC   (FAIL)
> 
> The issue here is that in the test it tries to open the file in O_READ,
> O_TRUNC mode which should ideally have returned EACCESS. But NFSv4 client
> maps it to OPEN with 'OPEN4_SHARE_ACCESS_READ' and since the owner has READ
> permissions, server rightly grants it.
> 
> That means both chown(00.t - #77) and open(07.t - #5, #7, #9) tests should
> be marked as Known_Issues.
> 
> 
> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
> 
> As both these failures are expected, these tests should be ignored. Marking
> this bug as ON_QA. Please re-open if there are any failures reported. Also,
> please cross-check the behaviour with kNFS as well. Thanks!

Based on the above comment I moving this BZ to other state