Accessing Kerberos NFS via /net automounter with kinit only (no /etc/krb5.conf access)

[Will Fiveash]

On Sat, Apr 12, 2014 at 09:50:25AM +0200, Wang Shouhua wrote:
> On 11 April 2014 22:14, Will Fiveash <will.fiveash at oracle.com> wrote:
> > On Tue, Apr 01, 2014 at 06:00:45PM +0200, Wang Shouhua wrote:
> >> I am on Solaris 10U4 - can I access a NFS filesystem with (mandatory)
> >> krb5p authentication via the Solaris /net automounter with kinit only,
> >> without having r/w access to /etc/krb5.conf access)?
> >
> > You'll need to have Solaris krb configured which stores its config in
> > /etc/krb5 not /etc as is the MIT default.  You'll also need read access
> > to /etc/krb5/krb5.conf and have the system properly configured to do NFS
> > with krb in general (read the Solaris 10 online docs).
> >
> > Beyond that, whether a user kinit'ing is enough depends on which version
> > of NFS you are using.  On the client side NFSv3 sec=krb5p shares will
> > automount if the user triggering the mount has a krb cred in their
> > ccache (klist will show that) and does not require any keys in the
> > system keytab nor does it require root to have a krb cred in general.
> >
> > NFSv4 on the other hand does require that the root on the NFS client
> > system have a krb cred in its ccache.  This can be done either by
> > running kinit as root or having at least one set of keys for either the
> > root/<host> or host/<host> service princ in the system keytab which will
> > be automatically used to acquire a krb cred for root.
> >
> > On the client system "nfsstat -m" will show what version of NFS is being
> > used.
> 
> We are talking about NFS version 4 (NFSv4) on Solaris only. Why does
> NFSv4 have such extra requirements?
> 
> What we hoped is that if a machine has Kerberos5 enabled it can
> connect to *any* other Keberos5 (krb5p/krb5i) filesystem, not only
> those in the current Kerberos5 realm, if kinit can be provided with
> the correct tickets. If it doesn't work then it looks like a bug to us
> (speaking for MOST.GOV.CN).
> 
> How can we get this fixed?

This is not a krb problem, it's an issue with the way NFSv4 was
implemented by many vendors including Solaris.  It's my understanding
that many Linux distros have the same requirements.

Here is some explanation about the issue sent to me by a NFS developer:

"Unlike NFS3, the NFS4 protocol is stateful, and a
 lease model is used to manage its state.
 
 After creating state tokens, NFS4 clients must periodically
 check-in with the NFS4 server to renew their state lease.
 If the state lease is not renewed, the server is free to
 expire the client’s lease and destroy its state.   This
 is precisely what happened to your client.
 
 The NFS4 client’s lease renewal thread runs as root (kcred),
 and when the client’s keytab doesn’t contain a host svc princ,
 kcred/root cannot be mapped to a kerberos principal.  The
 end result is that the renew thread cannot send its OP_RENEW
 to the server to renew its state lease."

You should ask about this issue on a NFS developer mail list.

-- 
Will Fiveash
Oracle Solaris Software Engineer