Ubuntu
nfs-utils package

nfs anonuid and anongid are not working uid,gid is always 65534

Bug #364937 reported by Pascal R.
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
nfs-utils (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I have installed nfs-kernel-server (1:1.1.2-4ubuntu1) on Ubuntu Alternate 8.10 and nfs-common (1:1.1.4-1ubuntu1) on Kubuntu 9.04.
There seems to be no way, to see the original uid and gid of the exported files on the client side. The uid and gid of every file is always 65534.
I configured both systems like described in the non-Kerberos part of this Ubuntu help:
https://help.ubuntu.com/community/NFSv4Howto/
and I did a lot of variations. I especially tried all combinations of no_all_squash, all_squash, no_root_squash, root_squash, no_subtree_check, subtree_check in the /etc/exports settings.
I also tried to use all_squash,anonuid=1000,anongid=1000 to map all uids and gids to 1000, but nothing happened. The uid and gid of every file is always 65534.
Every time I changed the /etc/exports settings file, I did a

sudo /etc/init.d/nfs-kernel-server restart

on the server, and a umount than a

/etc/init.d/nfs-common restart

and a remount of the nfs resource on the client.

See original description
Pascal R. (niun)
visibility: private → public
Brian Murray (brian-murray)
affects: ubuntu → nfs-utils (Ubuntu)
Pascal R. (niun)
description: updated
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

security vulnerability: yes → no
Revision history for this message
Pascal R. (niun) wrote :

It seems, that the anonuid and anongid options are working, but you cannot see that it is working. No matter what anonuid and anongid are set to, and as who you are logged in, "ls -l" shows nobody:nogroup as the owner of all files. But the rights are correctly given:

Some examples:
The exportet Files on the NFS server are belonging to user 1000 in group 1000
On the Client,
bob has uid 1000,
alice has uid 1001.

If anonuid and anongid are not set on the NFS server the files shoud belong to bob on the client:

bob@clientmachine:/nfsmount/$ ls -l test
-rw-r--r-- 1 nobody nogroup 0 2009-05-01 19:05 test
=> it looks like bob has no write access to the file "test", because bob!=nobody. But he has write access.

alice@clientmachine:/nfsmount/$ ls -l test
-rw-r--r-- 1 nobody nogroup 0 2009-05-01 19:05 test
=> it looks exactly the same, but alice has no write access to the file "test".

If anonuid and anongid are set to 1001 on the NFS server:

bob@clientmachine:/nfsmount/$ ls -l test
-rw-r--r-- 1 nobody nogroup 0 2009-05-01 19:05 test
=> it still looks the same, but bob has no write access to the file "test".

alice@clientmachine:/nfsmount/$ ls -l test
-rw-r--r-- 1 nobody nogroup 0 2009-05-01 19:05 test
=> now alice has write access to the file "test".

The rights are correctly given, but you won't see it with the "ls" command. I think, this is not exactly the desired behaviour.

Revision history for this message
cotillion (tobias-schwan) wrote :

I can confirm this. client: 9.10 server: 9.10

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nfs-utils (Ubuntu):
status: New → Confirmed
Revision history for this message
Ulf Renman (ulf-renman) wrote :

I can confirm this. client: 14.04.3 server: 8.04.4

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.