Re: NFSv4 without Kerberos and permissions
On 10/16/2017 07:57 PM, John Ratliff wrote:
> On 10/15/2017 3:38 AM, Christian Seiler wrote:
>> 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.
Sorry, you're right. rpc.mountd is typically only NFSv2/3, but with
NFSv4 it does provide some corner case functionality (I rechecked
the code just now) and MANAGED_GIDS is one of those.
>> 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.
Note that idmapping is not the same as Kerberos. idmapping just
means that you map between the user id and a string before any
ID is sent of the network. (Client translates user id to string,
sends string over network, server receives string, translates
it back to a user ID and uses that - and vice versa.)
NFSv4 without Kerberos _always_ has the same security properties,
irrespective of whether you enable idmapping or not: none.
If you want authentication you need sec=krb5. If you also want
data integrity and tamper-resistance, you need sec=krb5i. And
if you also want encryption you need sec=krb5p. In all of these
cases you need a Kerberos setup, which is not trivial.
Regards,
Christian
Reply to: