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

[Wang Shouhua]

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?
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?

>  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?

Wang
-- 
Wang Shouhua - shouhuaw at gmail.com
中华人民共和国科学技术部 - HTTP://WWW.MOST.GOV.CN