This discussion seems to be a bit fubar. So I start over again. I see three problems if $HOME is Kerberized NFS volume, I will call this NFS client machine. 1) user logs via SSH to the NFS client machine using GSS API, i.e., the user has a Kerberos ticket. SSHD on the NFS client machine has to access ~/.k5login under root identity (usually host identity). User has to grant access to such identity to his/her $HOME and .k5login in there. Older version of Kerberos denied access if ~/.k5login had different permision than 0600. 2) user logs via SSH to the NFS client machine using password. He/she stays logged in, Kerberos ticket expires. Issuing kinit returns an error I've already sent, because kinit wants to read ~/.krb5/config file and gets EKEYEXPIRED. Kinit does not deal with such an error, it understand olny EPERM error. New ticket cannot be created until user deletes ticket from TMPDIR (rm, not kdestroy as it does not work either). 3) user wants to log via SSH to the NFS client machine using ssh public key. This cannot be done as ~/.ssh/authorized_keys is accessed by SSHD under user context (not root context), so EPERM is returned even if user grants access to read ~/.ssh/authorized_keys to anyone. While nothing can be done ad 1). My proposed extension of rpc.gssd would solve ad 2) and ad 3). As this should be purely rpc.gssd patch, possible attacker with escalated root access is out of question because the attacker can replace rpc.gssd on his own. And also in this case, decision whether user gets EKEYEXPIRED/EPERM or granted access as some particular identity is desicion of the administator of the NFS client machine. -- 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
