Bug 508933 - uid/username rights mismatch using nfs4
uid/username rights mismatch using nfs4
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nfs-utils (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Steve Dickson
Depends On:
  Show dependency treegraph
Reported: 2009-06-30 11:14 EDT by Karel Volný
Modified: 2010-12-06 18:23 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-06 18:23:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2009-06-30 11:14:29 EDT
Description of problem:
When trying to test nfs4, I've found that file ownership reported is not the effective one, i.e. the command ls "lies".

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
at the server:
dd if=/dev/zero of=image count=4K
mkfs -t ext3 -F image
mkdir /export
mount -t ext3 -o rw,acl,loop image /export
chmod ugo+rwx /export
echo "/export  *(rw,nohide)" >> /etc/exports
service nfs restart
adduser guest
su - guest
echo "Hello World" > /export/foobar
chmod 600 /export/foobar

at the client:
adduser guest
adduser -u X -g Y guest2
(where X and Y match user guest at the server)
mkdir /mnt/import
mount -t nfs4 server:/export /mnt/import

Actual results:
ls reports user "guest" as the file owner:
# ls -l /mnt/import/foobar
-rw------- 1 guest guest 12 Jun 30  2009 /mnt/import/foobar

but "guest" cannot access the file:
.qa.[root@i386-5s-m2 tps]# su - guest
[guest@i386-5s-m2 ~]$ cat /mnt/import/foobar
cat: /mnt/import/foobar: Permission denied

while "guest2" can:

.qa.[root@i386-5s-m2 tps]# su - guest2
[guest2@i386-5s-m2 ~]$ cat /mnt/import/foobar
Hello World

Expected results:
"guest2" is reported as the file owner, while this user can access the file

Additional info:
I base this on http://nfs.sourceforge.net/nfs-howto/ar01s06.html -

"An example: bob on the server maps to the UserID 9999. Bob makes a file on the server that is only accessible the user (the equivalent to typing chmod 600 filename). A client is allowed to mount the drive where the file is stored. On the client mary maps to UserID 9999. This means that the client user mary can access bob's file that is marked as only accessible by him."

If this is not true for NFSv4, and the access is based on using the same username rather than on the same UID, so the ls command does not "lie", then the effective rights are wrong - and they doesn't seem to be affected by the advanced security mechanisms:

.qa.[root@i386-5s-m2 tps]# getfacl /mnt/import/foobar
getfacl: Removing leading '/' from absolute path names
# file: mnt/import/foobar
# owner: guest
# group: guest

.qa.[root@i386-5s-m2 tps]# nfs4_getfacl /mnt/import/foobar

.qa.[root@i386-5s-m2 tps]# ls -Z /mnt/import/foobar
-rw-------  guest guest system_u:object_r:nfs_t          /mnt/import/foobar
Comment 1 J. Bruce Fields 2010-12-06 18:23:18 EST
Results are as expected.  For NFS purposes users are identified in two ways:

1. RPC-level credentials carried in the rpc header determine "who" performs a given operation.  If using auth_sys (as in the example above), those credentials will take the form of numerical uid's and gid's.  If using auth_gss/krb5, the credentials will consist of cryptographic information including a context handle which can be mapped back to a krb5 principal.

2. In operations that set or query file owners and ACL entries, users and groups must be identified in the NFS operation.  NFSv3 uses uid's and gid's for this, while NFSv4 uses names.

So: when querying the owner attribute over NFSv4, the server correctly returns "guest@<yourdomain>" as the owner.  However, the rpc credentials sent across with the operations that perform the "cat /mnt/import/foobar", above, are numerical uid's and gid's.

Keep the client and server accounts in sync (either manually or using something like ldap), and this kind of problem should not happen.

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