Re: Fwd: RFC rpc.gssd enhancement

[Olga Kornievskaia <aglo@umich.edu>]

On Thu, Dec 8, 2016 at 4:50 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
> On Thu, Dec 8, 2016 at 4:22 PM, Lukas Hejtmanek <xhejtman@gmail.com> 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.