Bug 507527 - NFSD returns NFS4_OK when the owner opens a file with permission set to 000
NFSD returns NFS4_OK when the owner opens a file with permission set to 000
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.8
All Linux
medium Severity medium
: rc
: 4.9
Assigned To: Jeff Layton
Petr Beňas
:
: 487108 (view as bug list)
Depends On:
Blocks: 589293
  Show dependency treegraph
 
Reported: 2009-06-23 03:48 EDT by Harshula Jayasuriya
Modified: 2015-01-04 17:58 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-16 10:59:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch from Fujitsu (I removed whitespace modifications) (1.60 KB, patch)
2009-06-23 04:02 EDT, Harshula Jayasuriya
no flags Details | Diff

  None (edit)
Description Harshula Jayasuriya 2009-06-23 03:48:56 EDT
Details from Fujitsu:
------------------------------------------------------------
RHN System ID:

Customer Contact Name:

Ishikawa Yoshitaka

Description of Problem:

Server Kernel returns NFS4_OK when an ordinary user opening a file which he owns and permission is set to 000
On any other file systems (ext3, ext4, nfsv3 etc.), an ordinary user can not open a file which permission is set to 000 even if he is the owner of the file.
So, on NFSv4 fs, when an ordinary user opening a file which he owns and permission is set to 000, kernel should return an error NFS4ERR_ACCESS rather than NFS4_OK.

Version-Release number of selected component:

Red Hat Enterprise Linux Version Number: RHEL4
Release Number:    4.8 snapshot5
Architecture:      x86_64
Kernel Version:    kernel-2.6.9-88.EL
Related Package Version:    none
Related Middleware / Application:    none

Drivers or hardware or architecture dependency:

None

How reproducible:

Every time

Step to Reproduce:

Server Settings:
  # cat /etc/exports
  /tmp *(rw,insecure,fsid=0,root_squash)

Client:
  Execute following commands to reproduce (root is treated as a ordinary
  user because the server export the fs with option 'root_squash'.):

  Step1:mount the nfsv4 fs and enter the mount dir
      # mount -t nfs4 [server]:/ /mnt/ && cd /mnt/
  Step2:creat the test file
      # echo "test" > test
  Step3:change the test file permission to 000
      # chmod 000 test
  Step4:cat the test file
      # cat test

Actual Results:

The file content is displayed.

$ cat test
test

Expected Results:

"Permission denied" is outputted.

$ cat test
cat: test: Permission denied

Summary of actions taken to resolve issue:

None

Location of diagnostic data:

None

Hardware configuration:

Model:       PRIMERGY TX150 S5
CPU Info:    Intel(R) Xeon(R) CPU   3040  @ 1.86GHz
Memory Info: 6GB

Business Impact:

None
Target Release: 4.9
Errata Request: No
Hotfix Request: No
------------------------------------------------------------

Additional Info:
* I was able to reproduce the problem.
* RHEL5 Bug 502244 - 'r' and 'w' permission for user do not work on NFSv4 client
* RHEL5 patch: linux-2.6-nfs-v4-r-w-perms-for-user-do-not-work-on-client.patch
Comment 1 Harshula Jayasuriya 2009-06-23 04:02:04 EDT
Created attachment 349052 [details]
patch from Fujitsu (I removed whitespace modifications)

I have tested this patch and it fixes this problem.
Comment 2 RHEL Product and Program Management 2009-08-31 14:34:18 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 7 Vivek Goyal 2010-09-17 13:51:03 EDT
Committed in 89.36.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Comment 9 Jeff Layton 2010-10-12 20:19:11 EDT
*** Bug 487108 has been marked as a duplicate of this bug. ***
Comment 13 Petr Beňas 2010-10-20 09:35:52 EDT
reproduced in 2.6.89.35.EL and verified in 2.6.9.89.36.EL.
Comment 16 errata-xmlrpc 2011-02-16 10:59:30 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0263.html

Note You need to log in before you can comment on or make changes to this bug.