Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)

[Will Fiveash]

On Tue, Apr 15, 2014 at 03:13:09PM -0400, Simo Sorce wrote:
> On Tue, 2014-04-15 at 13:48 -0500, Will Fiveash wrote:
> > On Tue, Apr 15, 2014 at 11:36:34AM -0500, Nico Williams wrote:
> > > Will,
> > > 
> > > Mobile devices don't really have stable hostnames, so the system
> > > should support non-hostbased host/root credentials.
> > 
> > If you are referring to the NFS v4 client requiring root have a krb cred
> > in order to function as I described in an earlier e-mail I would ask why
> > NFS v4 clients require root to have a krb cred in the first place (NFS
> > v3 doesn't as you may recall)?  As you can imagine, many IT departments
> > would balk (putting it mildly) if they were asked to provision keytabs
> > on laptops or other mobile devices that need access to krb protected NFS
> > v4 shares.
> > 
> > As to how that requirement happened, according to one of the NFSv4
> > developers here that regularly attends Connectathon, the consensus among
> > the NFS v4 implementors for various Linux platforms was that a properly
> > configured NFS v4 client meant it had a keytab containing host service
> > princ keys which could then be leveraged to protect the lease renewal
> > traffic.  My opinion is that unless there is a very good reason to
> > protect that traffic, krb protection for lease renewal traffic should be
> > optional, depending on configuration.
> 
> 
> There is a good reason to require a keytab on a client if you use
> kerberos for authentication to the machine, and that is that you need
> validation for login.
> 
> You also need a host key if you want to allow to use gssapi
> authentication for ssh.
> 
> So it is not too far fetched to expect to find a host key on every
> machine participating to a kerberos REALM.

But if this is a work laptop, which is typically a single user system
and operates as a client in various contexts, requiring IT provision it
with a keytab seems onerous to me.  Note that a Solaris NFS v3 client
does not require root have a krb cred to operation, even when
automounting -- it only requires the user that triggered the automount
have a krb cred.

> That said it is unclear to me why the NFSv4 server should try to use a
> new channel to communicate with the client instead of just using the
> existing channel the client opened against the server.

I think part of the problem is that the gss security context protecting
the channel along with the user's krb cred could expire at any time.  I
think that's why they wanted root to use a key stored in the keytab (I
could be wrong of course).

-- 
Will Fiveash
Oracle Solaris Software Engineer