Red Hat Bugzilla – Bug 508933
uid/username rights mismatch using nfs4
Last modified: 2010-12-06 18:23:18 EST
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):
Steps to Reproduce:
at the server:
dd if=/dev/zero of=image count=4K
mkfs -t ext3 -F image
mount -t ext3 -o rw,acl,loop image /export
chmod ugo+rwx /export
echo "/export *(rw,nohide)" >> /etc/exports
service nfs restart
su - guest
echo "Hello World" > /export/foobar
chmod 600 /export/foobar
at the client:
adduser -u X -g Y guest2
(where X and Y match user guest at the server)
mount -t nfs4 server:/export /mnt/import
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
"guest2" is reported as the file owner, while this user can access the file
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
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.