Bug 216343

Summary: uid <-> username mapping oddities in NFSv4
Product: [Fedora] Fedora Reporter: Fabrice Bellet <fabrice>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED WONTFIX QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: fabrice, triage
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 12:52:18 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Fabrice Bellet 2006-11-19 12:22:44 EST
Hi!

I enter a bugzilla entry for this behaviour, altough I'm not sure if this is the
regular way nfsv4 is supposed to work or not. Anyway, it looks odd to me, so
here we go.

I try to setup an nfsv4 share between two machines, where uid/gid for a given
username don't match.  The uid <-> username translation is correct when I issue
an "ls -l" client-side on the shared directory.  What seems incorrect to me is
that, when I create files on the share client-side, they are created with the
uid/gid of the client-side process, meaning that no uid->username translation
occurs in this way.

Client and server run FC-6 with nfs-utils-1.0.10-3.fc6 and
nfs-utils-lib-1.0.8-7.2.  I configured /etc/idmapd.conf identically on both
client and server :

[General]

Verbosity = 9
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = bellet.info

[Mapping]

Nobody-User = nobody
Nobody-Group = nobody

[Translation]
Method = nsswitch

===> My exports file contains a single entry:
/home/bellet/media *.bellet.info(rw,sync,fsid=0)

===> And I mount the share on the client with:
mount helix:/ /tmp/1 -tnfs4

Here is a log of what happens. On the server (helix), my uid/gid is
555/555, and on the client (lxorgfr) 500/500:

===> On the server, the shared directory and its content are owned by
bellet/bellet 555/555:

[root@helix media]# ls -l
total 24
drwxr-xr-x 24 bellet bellet 4096 Nov 19 11:55 audio
drwxrwxr-x  2 bellet bellet 4096 Nov 19 11:55 misc
drwxrwxr-x 16 bellet bellet 4096 Nov 19 11:55 videos
[root@helix media]# id bellet
uid=555(bellet) gid=555(bellet) groups=555(bellet),6(disk),102(cvs)

===> I execute the mount command :

[root@lxorgfr bellet]# mount helix:/ /tmp/1 -tnfs4

===> Log on the client:

Nov 19 12:30:06 lxorgfr rpc.idmapd[31207]: New client: 10
Nov 19 12:30:06 lxorgfr rpc.idmapd[31207]: Opened
/var/lib/nfs/rpc_pipefs/nfs/clnt10/idmap
Nov 19 12:30:06 lxorgfr rpc.idmapd[31207]: nss_getpwnam: name
'bellet@bellet.info' domain 'bellet.info': resulting localname 'bellet' 
Nov 19 12:30:06 lxorgfr rpc.idmapd[31207]: Client 10: (user) name
"bellet@bellet.info" -> id "500"
Nov 19 12:30:06 lxorgfr rpc.idmapd[31207]: Client 10: (group) name
"bellet@bellet.info" -> id "500"
Nov 19 12:30:06 lxorgfr kernel: SELinux: initialized (dev 0:16, type nfs4), uses
genfs_contexts

===> Log on the server:

Nov 19 12:29:23 helix rpc.idmapd[4050]: libnfsidmap: using domain: bellet.info 
Nov 19 12:29:23 helix rpc.idmapd[4050]: libnfsidmap: using translation method:
nsswitch 
Nov 19 12:29:23 helix rpc.idmapd[4051]: Expiration time is 600 seconds.
Nov 19 12:29:23 helix rpc.idmapd[4051]: Opened /proc/net/rpc/nfs4.nametoid/channel
Nov 19 12:29:23 helix rpc.idmapd[4051]: Opened /proc/net/rpc/nfs4.idtoname/channel
Nov 19 12:30:06 helix rpc.idmapd[4051]: nfsdcb: authbuf=*.bellet.info authtype=user
Nov 19 12:30:06 helix rpc.idmapd[4051]:  Server: (user) id "555" -> name
"bellet@bellet.info"
Nov 19 12:30:06 helix rpc.idmapd[4051]: nfsdcb: authbuf=*.bellet.info authtype=group
Nov 19 12:30:06 helix rpc.idmapd[4051]:  Server: (group) id "555" -> name
"bellet@bellet.info"

===> On the client:

[root@lxorgfr bellet]# ls -l /tmp/1/
total 24
drwxr-xr-x 24 bellet bellet 4096 Nov 18 21:48 audio
drwxrwxr-x  2 bellet bellet 4096 Nov 18 20:53 misc
drwxrwxr-x 16 bellet bellet 4096 Mar 29  2006 videos
[root@lxorgfr bellet]# id bellet
uid=500(bellet) gid=500(bellet)
groups=500(bellet),5(tty),6(disk),20(games),101(sysadmin),102(cvsextras),504(sbox),410(fuse),411(mock)

===> Here, I can see that names are correctly translated from uid 555 on
the server to the username associated with uid 500 on the client.
===> Then, I try to create a file on the client as uid 500:

[bellet@lxorgfr bellet]% touch /tmp/1/foo
[bellet@lxorgfr bellet]% ls -l /tmp/1/foo
-rw-r--r-- 1 nobody nobody 0 Nov 19 12:32 /tmp/1/foo
[bellet@lxorgfr bellet]% ls -ld /tmp/1
drwxrwxrwx 5 bellet bellet 4096 Nov 19 12:32 /tmp/1

===> On the server, the file is created with uid=500 :

[root@helix ~]# ls -l /home/bellet/media/
total 24
drwxr-xr-x 24 bellet bellet 4096 Nov 18 21:48 audio
-rw-r--r--  1    500    500    0 Nov 19 12:32 foo
drwxrwxr-x  2 bellet bellet 4096 Nov 18 20:53 misc
drwxrwxr-x 16 bellet bellet 4096 Mar 29  2006 videos

===> Log on the client:

Nov 19 12:32:48 lxorgfr rpc.idmapd[31207]: nss_getpwnam: name 'nobody' domain
'bellet.info': resulting localname '(null)' 
Nov 19 12:32:48 lxorgfr rpc.idmapd[31207]: nss_getpwnam: name 'nobody' does not
map into domain 'bellet.info' 
Nov 19 12:32:48 lxorgfr rpc.idmapd[31207]: Client 10: (user) name "nobody" -> id
"99"
Nov 19 12:32:48 lxorgfr rpc.idmapd[31207]: Client 10: (group) name "nobody" ->
id "99"

===> Log on the server:

Nov 19 12:32:48 helix rpc.idmapd[4051]: nfsdcb: authbuf=*.bellet.info authtype=user
Nov 19 12:32:48 helix rpc.idmapd[4051]:  Server: (user) id "500" -> name "nobody"
Nov 19 12:32:48 helix rpc.idmapd[4051]: nfsdcb: authbuf=*.bellet.info authtype=group
Nov 19 12:32:48 helix rpc.idmapd[4051]:  Server: (group) id "500" -> name "nobody"

I've read on the nfs mailing-lists that this is the way is works, because
underlying rpc calls only contains uid/gid numbers in their credentials: 
http://linux-nfs.org/pipermail/nfsv4/2004-June/000088.html

OTOH, this IBM document on AIX NFS describes the expected behaviour, page 50 :
http://www.redbooks.ibm.com/redbooks/pdfs/sg247204.pdf

From the user point of view, the current behaviour with AUTH_SYS is misleading,
because he sees on the client, files and directories that he owns, but where he
cannot write in. Is there a configuration tweak that I forgot somewhere ?
Comment 1 Steve Dickson 2007-01-12 14:41:28 EST
If I'm undertanding this correctly I believe an unknown user should
be mapped into the "nobody" user id... 
Comment 2 Fabrice Bellet 2007-01-22 13:44:43 EST
The behaviour that I don't understand is, why does my uid/gid on the client
(500/500) appear untranslated on the server when I create a file on the client,
see the last "log on the server", containing the line:

Nov 19 12:32:48 helix rpc.idmapd[4051]:  Server: (user) id "500" -> name "nobody"

My understanding of nfsv4 is that uid 500 should stay local to the client, and
should not be sent on the wire to the server. but instead "bellet@bellet.info"
should. The behaviour that I expect is described in Figure3-1 on page 51, in the
IBM document.

Ideally, file ownership should be translated both when getting its attributes
(from server to client: that's currently ok), but also when creating it (from
client to server: that's where a problem lies IMO).
Comment 3 Steve Dickson 2007-03-12 13:23:35 EDT
What are you using to do the name to uid translation? NIS, ldap, ??
Comment 4 Fabrice Bellet 2007-03-12 14:58:30 EDT
I use the local /etc/passwd file for name to uid translation.
Comment 5 Bug Zapper 2008-04-04 00:47:32 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 6 Bug Zapper 2008-05-06 12:52:16 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.