nfsv4 sec=krb5p and user impersonation

[Matt Garman]

On Tue, Sep 9, 2014 at 5:22 PM, Cedric Blancher
<cedric.blancher at gmail.com> wrote:
> I think part of the problem is that you are using Linux (SLES, RHEL or
> Centos doesn't matter), and the Linux NFS client implementation does
> not support negotiation for the authentication in violation of RFC
> 3530.
>
> So if you want to use Kerberos5 with NFS on SLES or RHEL/Centos you a)
> must have proper tickets in your cache and use kswitch before calling
> mount and b) you must always specify auth=krb5p or krb5i if you want
> Kerberos authentication.

I think there are two (at least?) "authentications" taking place, and
you might be addressing the wrong one.  It's also possible that I'm
hopelessly lost, but bear with me.  :)

I would call "authentication 1" the *machine's* authentication that
allows the mount to take place.  All the client servers do the mount
at boot-time.  I have created machine principles in my kerberos
database.  Each machine has its specific key exported to
/etc/krb5.keytab so that it can do a krb5p mount.

Though Linux may not support authentication negotiation, I don't
believe I care, as I have the exported shares set up for krb5p only.
Likewise, on each client machine's /etc/fstab file, I explicitly pass
the sec=krb5p option to mount.nfs4.

So I *think* I have the mounting setup correct.

What I call "authentication 2" is the actual user- and file-level
permissions, i.e. who can see what file.  The share is mounted
regardless.  But at this point, under what circumstances is root
allowed to see various users' files?  How is it that root can
"authenticate" as user XYZ without knowing XYZ's password, under the
case I outlined in the original email?

Thanks!
Matt