[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NFSv4 without Kerberos and permissions

On 10/15/2017 3:38 AM, Christian Seiler wrote:
On 10/15/2017 03:55 AM, John Ratliff wrote:
In my case, the user on the client I was testing was UID 1003, which
on the server he was UID 1000. So they both had the group, but UID
1003 on the server did not have the group, because that user did not
exist. Therefore, permission denied.

Then you are not idmapping correctly.

NFSv4 has two modes of operation when it comes to users:

  1) Use raw UIDs/GIDs like NFSv2/3 did. This is available since Linux
     3.2 or 3.5 (I don't remember which) and only possible if sec=sys
     (i.e. no Kerberos) is used. In that case the user IDs are simply
     sent over the wire directly.

     This requires the UIDs and GIDs to be identical on client and

  2) Use names for users / groups. Each user and group is translated
     into a string on the client, and the server translates the string
     back to a user id. This is done via the idmapping mechanism
     (rpc.idmapd on the server side, and nfsidmap in combination with
     request-key on the client side, both configured via
     /etc/idmapd.conf). Here the UIDs/GIDs don't need to be identical
     on client and server.

In your case, since you are not using Kerberos, current Linux
versions will default to not using the ID mapping mechanism when a
non-Kerberos setup is in place, and will use raw UIDs/GIDs instead.
But you _do_ want idmapping since the the UIDs and GIDs on the client
and/or server don't match up.

To make this work, you can tell the server to never accept raw UIDs
and GIDs:

echo 0 > /sys/module/nfsd/parameters/nfs4_disable_idmapping

The setting is a bit of a misnomer: while it is on by default, the
setting does not actually disable idmapping on the server, it being
on will just also enable raw UIDs and GIDs. If a client that
connects doesn't support raw UIDs/GIDs (such as older Linux versions
e.g. 2.6.x or other operating systems) the server will still happily
do idmapping with the setting on. But disabling this setting will
have the NFS server fall back to the mode where it will only accept
idampped strings and never accept raw UIDs/GIDs. This will cause
some log messages to be shown in recent enough Linux clients (the
message being "v4 server [...] does not accept raw uid/gids.
Reenabling the idmapper", but that's actually the behavior you want.

To make the setting permanent, you may add it to your modprobe.conf:

echo "options nfsd nfs4_disable_idmapping=0" > /etc/modprobe.d/nfsd.conf

There is also a setting for the clients here, found in
/sys/module/nfs/parameters/nfs4_disable_idmapping (note the missing
'd' in the module name) that works just the same, but only on the
client side.

I am not aware of any way to change this setting on a per-mount

It is up to you whether you'll want to add this setting on the server,
the clients, or both.

Thanks. This all worked great. Once I disabled the setting on both the server and the client, ID mapping started working.

In an unrelated note:

Although it's not the best solution from a security standpoint, I'm
going to disable the manage-gids option for now and limit access by
hosts.allow and the firewall.

NFSv4 without Kerberos does not have any security at all. The server
will implicitly trust the UID the client sends to the server, so a
compromised client may impersonate any (!) user on the server except
root (unless no_root_squash is set in /etc/exports, which I don't
recommend). It may also impersonate any group.

Furthermore, the MANAGED_GIDS setting is only for NFSv2/3 and only
for supplementary groups, not the primary group. It is not a security
setting, it really is just for bypassing the 16 group limit of older
NFS protocols, and is useless with NFSv4.

I'm not sure this is entirely the case. Turning off managed GIDs and using an NFSv4 mount (i.e. on client: mount -t nfs4 blahblahblah), this let me use secondary groups on the server. Before, I could not.

Basically, if you're running a sec=sys NFS server (or an NFSv2/3
server) you're implicitly trusting all the clients that are allowed
to connect to you and all the network components (such as routers)
in the middle. Anything that is not owned by the root user will be
able to be read or written to by any NFS client if the client wants
to: they can just read out the user ID of the file and send that
to the server together with the read/write request. Only the root
user is a bit more protected due to root_squash, and you can make
the entire export read-only - but that's it when it comes to the
protections NFS without Kerberos gives you.

Thanks. This has been quite helpful. I will adjust the configurations on my actual servers to make use of ID mapping there as well.


Reply to: