On Thu, Dec 8, 2016 at 7:36 AM, Lukas Hejtmanek <xhejtman@xxxxxxxxx> wrote: > 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. > Why is "kinit" accessing ~/.krb5/config? Typically kinit will only access /etc/krb5.conf. You are describing a catch-22 system. You want to create credentials but to create credentials you need to access a file that is protected by the credentials. This is a badly designed setup. kinit normally does not require access into something that is protected by credentials gotten by kinit. Your solution is to provide your user with "kinit" that does not access ~/.krb5/config. Please describe the need for that file and why it can't be satisfied using machine global /etc/krb5.conf. -- 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
