Does NFS client need a running idmapd ?

English Network/Internet
1

Hi all,

my problem is: files shared on NFS server all get uid=0 and gid=0 on the client.

Name/ID mapping, i.e. getent passwd/group, is the same on client and server (source is LDAP). Authentication is done with Kerberos (sec=krb5). The client is running Tumbleweed.

I read in different places that the service idmapd must run on the client for the mapping to work. But the configuration of the (static!) systemd service /usr/lib/systemd/system/nfs-idmapd.service depends on a running nfs-server service:


[Unit]
Description=NFSv4 ID-name mapping service
DefaultDependencies=no
Requires=var-lib-nfs-rpc_pipefs.mount
After=var-lib-nfs-rpc_pipefs.mount local-fs.target

BindsTo=nfs-server.service

[Service]
Type=forking
ExecStart=/usr/sbin/rpc.idmapd

So my question is: how is a openSuSE client correctly configured to do the mapping?

Thanks for any help!

2

I don’t have experience with kerberised NFS, but from a quick read of this bug report it appears that

The NFSv4 client uses the keyring-based idmapper nfsidmap. nfsidmap is a stand-alone program that is called by the kernel on-demand to perform ID mapping; it is not a daemon.

From ‘man nfsidmap’ I note

DESCRIPTION
The file /usr/sbin/nfsidmap is used by the NFS idmapper to translate user and group ids into names, and to translate user and
group names into ids. Idmapper uses request-key to perform the upcall and cache the result. /usr/sbin/nfsidmap is called by
/sbin/request-key, and will perform the translation and initialize a key with the resulting information.

   nfsidmap  can  also  used to clear the keyring of all the keys or revoke one particular key.  This is useful when the id mappings
   have failed to due to a lookup error resulting in all the cached uids/gids to be set to the user id nobody.
3

Thanks for the information, that answers my question.

So on the NFS server (CentOS 7) the rpc.idmapd service does the mapping and on the NFS client (Tumbleweed) it’s done by the kernel calling nfsidmap.

Now I’m totally stuck because I don’t know if things are going wrong on the server or the client. I set up another client (Ubuntu) to compare the behaviour, and it also shows uid=0, gid=0. So this might be a problem with the configuration of the CentOS server.

On the server I didn’t find much information about what’s going on:

sudo journalctl -u nfs-idmapd
systemd[1]: Starting NFSv4 ID-name mapping service...
systemd[1]: Started NFSv4 ID-name mapping service.

On the Tumbleweed client I found more (on Ubuntu the output is the same, only the nfsidmap -l is not supported):

sudo dmesg | grep id_resolver
   16.367268] NFS: Registering the id_resolver key type
   16.367275] Key type id_resolver registered

sudo grep id_resolv /proc/keys
0c70fea6 I--Q---     1   8m 3b010000     0     0 id_resolv uid:root@mydomain: 2
20861342 I--Q---     1   8m 3b010000     0     0 id_resolv gid:root@mydomain: 2
32e80522 I------     1 perm 1f030000     0     0 keyring   .id_resolver: 2

sudo nfsidmap -l
2 .id_resolver keys found:
  gid:root@mydomain
  uid:root@mydomain

Seems like the server is already telling the client that the files belong to root. But I’m not sure about that either.

I think I’ll post this on serverfault later and put a link here.

Thanks again!

4

I am not using such extras on NFS (like @deano_ferrari), but read this out of (NFS) curiosity.

IMHO you can be sure that the problem is on the server. Simply because it would be a huge security hole as a client could treat any imported files as belonging to root out of the clients own will. Thus it must be the server that compromises security by exporting these files as belonging to root to anybody who is interested in it