Re: NFSv4 without Kerberos and permissions
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
server.
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
basis.
It is up to you whether you'll want to add this setting on the server,
the clients, or both.
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.
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.
Regards,
Christian
Reply to: