On Mon, Apr 14, 2014 at 08:55:10PM +0200, Wang Shouhua wrote: > 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?
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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
