Return-Path: Received: from mail-io0-f172.google.com ([209.85.223.172]:33821 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932933AbcLHV6T (ORCPT ); Thu, 8 Dec 2016 16:58:19 -0500 Received: by mail-io0-f172.google.com with SMTP id p42so28143418ioo.1 for ; Thu, 08 Dec 2016 13:58:19 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20161129184843.jrwbnytggrz6kdir@ics.muni.cz> <2ff5b760-a3ca-9ab8-d1a8-efe5f36aaaf3@RedHat.com> <20161202114134.rvzqptnsqo3odxay@ics.muni.cz> <20161202134638.4ghyb5wnnwata4ec@ics.muni.cz> <20161202142847.vyhp6ogtu6gvuabf@ics.muni.cz> <20161208123616.nndod3snzoeyr565@ics.muni.cz> <20161208212238.ctyshbcpz7afzrxv@ics.muni.cz> From: Olga Kornievskaia Date: Thu, 8 Dec 2016 16:58:18 -0500 Message-ID: Subject: Re: Fwd: RFC rpc.gssd enhancement To: Lukas Hejtmanek Cc: Andy Adamson , NFS list Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Thu, Dec 8, 2016 at 4:50 PM, Olga Kornievskaia wrote: > On Thu, Dec 8, 2016 at 4:22 PM, Lukas Hejtmanek wrote: >> On Thu, Dec 08, 2016 at 04:11:38PM -0500, Olga Kornievskaia wrote: >>> 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. >> >> debian heimdal 1.6~rc2+dfsg-9 opens ~/.krb5/config and ~/.rnd files. >> dunno why. >> >> MIT implementation does not seem to access $HOME. > > When you say "MIT implementation does not seem to access $HOME", do > you mean you've build kinit from MIT source and it works? If so, then > solution seems to be to bug debian folks to investigate what happened > to their kinit? > For instance RHEL/CentOS 7 had an issue where there patched OpenSSH > looked at .k5login file where normal ssh didn't and caused problems: > https://bugzilla.redhat.com/show_bug.cgi?id=1328243 > > I think that might be related to your other complaint with using ssh > keys to ssh. But at the same time I can see that what's going on here > is again somewhat un-kosher. If you placed .authorized_key under > something that only user with credentials can access, then you can't > get to it without having though credentials. You have mentioned that > "authorized_key" are readable but typically ~/.ssh had 700 permission > so sshd can't get to reading "authorized_keys" file. > > To summarize: i suggest that you check that if an upstream kinit (from > MIT) and upstream openssh have the problems you are describing. Sorry you said debian heimdal not MIT. If MIT works, I suggest bringing this issue up on the heimdal kerberos mailing list and describe the problem there.