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
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
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:
Last Closed: 2011-02-16 10:59:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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:


How reproducible:

Every time

Step to Reproduce:

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

  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

Expected Results:

"Permission denied" is outputted.

$ cat test
cat: test: Permission denied

Summary of actions taken to resolve issue:


Location of diagnostic data:


Hardware configuration:

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

Business Impact:

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
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 and verified in
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.


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