On Tue, Nov 29, 2016 at 02:28:10PM -0500, Steve Dickson wrote: > > maybe it is not considered secure, but it is still more secure to me than > > using sec=sys. > True. So, I was asking, if I provide such patch, will it be accepted into mainline nfs-utils? > > the problem is, that kerberized home is problem for .k5login file and also for > > .ssh/authorized_keys. While the .k5login file is accessed with root context > > (sshd), the authorized_keys is accessed with user context, so login via ssh > > pubkey is not possible at all. > What would the .k5login look like and what would the principal look like? > My apologies but I'm not very familar with how sshd interacts with > the .k5login. ok, I did more testing. It seems that kinit does not search ~/.k5login but ~/.krb5/config. If NFS client gets permission denied, it is ok and kinit just creates a new ticket. However, if user has ticket that expired, NFS client returns EKEYEXPIRED instead of EPERM. In such a case, kinit/kdestoy does not deal with this errno and returns: kinit: krb5_init_context failed: 127 or kdestroy: krb5_init_context failed: 127 if you do rm /tmp/krb5cc_`id -u`_*, EKEYEXPIRED is changed to EPERM and kinit/kdestroy works again. Colleague of me says that EKEYEPIRED should not be returned by NFS client at all, EPERM should be always returned and he sees this as a bug in kernel code. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
