On 13 April 2014 21:59, Will Fiveash <[email protected]> wrote: > On Sat, Apr 12, 2014 at 09:50:25AM +0200, Wang Shouhua wrote: >> On 11 April 2014 22:14, Will Fiveash <[email protected]> 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 - [email protected] 中华人民共和国科学技术部 - HTTP://WWW.MOST.GOV.CN ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
