11:27 a.m.
Some things to consider:
Yes, setting SecType to only allow Kerberos will then require a Kerberos ticket for any
access (including NFS v3 mount).
The client may use a service principle for some actions. This I believe maps to root.
This
must be allowed during a mount (possible exception, I'm not sure if a mount is
performed by a non-root user if NFS does the mount access then using that user's
credentials). This means that the Ganesha host will have to have each client's
service
principle in its keytab which means that isn't a way to exclude root access. The
principle will allow root requests to be accepted, and then squashed.
Many thanks - this post got me digging deeper into the debug logs and what exactly was
happening at mount versus ls on the client, and my previous assumptions on how things were
working was incorrect.
It turns out that the mount is using the client's krb5 'host' principal to
authenticate the mount. Moving the keytab sideways and restarting rpc-gssd means the
client is forbidden from mounting.
So from a security perspective an untrusted machine without a host principal can't
mount at all, which is exactly what I was hoping for.
Any account on the client that doesn't then have it's own krb5 ticket will result
in idmapd on the server squashing them to 'nobody'.
Obviously it would be nice if we could enforce that both the host and the user must have a
valid ticket to get any fs access, but your explanation of why this wouldn't work for
root means this isn't likely to happen. (Though this is really only thinking of
untrusted users on trusted machines, which is a whole different issue security-wise!)
Thanks once again for helping clarify everything!
Matthew