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): nfs-utils-1.0.9-40.el5.i386 kernel-2.6.18-128.1.14.el5.i686 How reproducible: always 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 user::rw- group::--- other::--- .qa.[root@i386-5s-m2 tps]# nfs4_getfacl /mnt/import/foobar A::OWNER@:rwatTcCy D::OWNER@:x A:g:GROUP@:tcy D:g:GROUP@:rwaxTC A::EVERYONE@:tcy D::EVERYONE@:rwaxTC .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.