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

Will Fiveash will.fiveash at oracle.com
Tue Apr 15 00:08:32 EDT 2014


On Mon, Apr 14, 2014 at 08:55:10PM +0200, Wang Shouhua wrote:
> On 13 April 2014 21:59, Will Fiveash <will.fiveash at oracle.com> wrote:
> > 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),
> 
> 1. Is that just root/ or does that include host/ or nfs/ creds, too?

On Solaris the code first looks for root/<hostname> service princ keys
in the keytab then host/<hostname> keyes.

> 2. If you look at
> http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/fs.d/nfs/nfsd/
> where is the code which does that state update?
> 3. Does nfsd log any errors if the state lease cannot be renewed?

I don't know.  You may want to ask about that on a Oracle OTN discussion
forum (google that).

> >  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.
> 
> Which list is that?

Don't know off the top of my head as I work on Solaris krb.  If I get
the answer from a Oracle NFS developer I'll let you know.

-- 
Will Fiveash
Oracle Solaris Software Engineer


More information about the Kerberos mailing list