[38597] in Kerberos
Re: krb5 library missing functions for collections
daemon@ATHENA.MIT.EDU (Charles Hedrick)
Thu Aug 15 10:01:43 2019
From: Charles Hedrick <hedrick@rutgers.edu>
To: Jakub Hrozek <jhrozek@redhat.com>
Date: Thu, 15 Aug 2019 14:01:15 +0000
Message-ID: <66D708A7-6FAA-42FD-A8BE-DA18E9B9C226@rutgers.edu>
In-Reply-To: <20190730081702.gdcmli24ebmdpazv@kyubey>
Content-Language: en-US
Content-ID: <F80DB9F87C40814CA670F82FC0011070@namprd14.prod.outlook.com>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Jul 30, 2019, at 4:17 AM, Jakub Hrozek <jhrozek@redhat.com> wrote:
>
> On Mon, Jul 29, 2019 at 02:35:40PM -0400, Robbie Harwood wrote:
>> Greg Hudson <ghudson@mit.edu> writes:
>>
>>> On 7/22/19 1:39 PM, Charles Hedrick wrote:
>>>
>>>> Please be aware that I’m using Redhat’s KCM implementation in
>>>> sssd. It’s supposed to be compatible with Heimdal’s, but based on
>>>> documentation it appears that it may not be.
>>>>
>>>> The default value of KRB5CCNAME is simply KCM: It had better be
>>>> user-specific, or everybody shares a collection.
>>>
>>> The Heimdal KCM implements a single global collection with access
>>> control on individual caches, with the euid and egid of the client as
>>> the access keys. If a client doesn't have access to a cache, it isn't
>>> visible in the collection as presented to that client. Clients can
>>> only create ccaches with names beginning with their "<euid>:" prefix.
>>>
>>> In practice, users other than root will typically see disjoint
>>> collections, where each cache name begins with the client's euid. But
>>> that's not a fundamental property of the daemon, and therefore not an
>>> assumption of either the MIT krb5 or Heimdal client code.
>>>
>>> One could conceivably build this namespace assumption into the client,
>>> retrofitting it to treat "KCM:uid" as a collection by filtering out
>>> caches whose names don't begin with the uid prefix. Unfortunately
>>> that wouldn't be 100% backward-compatible, as the Heimdal kcm daemon
>>> allows clients to create individual caches named with only the euid
>>> (with no ":" afterwards). Perhaps that's not important, though.
>>>
>>> The sssd KCM may have different semantics from Heimdal's. If it doesn't
>>> let root see caches owned by other uids, then that would also have to be
>>> changed to allow "KCM:uid" to work for root.
>>
>> (CCing Jakub in case I miss anything here.)
>>
>> To my reading, SSSD's KCM deliberately allows root to access all ccaches
>> but not list them. See
>> https://github.com/SSSD/sssd/blob/master/src/responder/kcm/kcmsrv_ccache.h#L75-L80
>> and
>> https://github.com/SSSD/sssd/blob/master/src/responder/kcm/kcmsrv_ccache.h#L144-L156
>
> Hrm, maybe that comment is outdated. I thought, after discussing this
> with Greg some time ago:
> https://github.com/krb5/krb5/pull/557#issuecomment-254834623
> is that only KRB5CCNAME=KCM: is allowed and not KRB5CCNAME=KCM:uid and
> the only way root can access other user's ccaches is to run klist -l and
> filter by UID.
>
> However, running:
> KRB5CCNAME=KCM: klist -l
> as root does not allow me to list all users' ccaches as root..I haven't
> tested if this would have worked with MIT's libkrb5 and Heimdal's KCM,
> though..
I can actually do the combination of MIT libkrb5 and Heimdal KCM. I’m assuming that the Mac has a normal Heimdal KCM.
With Mac (Heimdal) klist
user clh:
klist -l
* clh@CS.RUTGERS.EDU API:51BC99CE-119B-42AC-8021-2B5DDE644A42 Aug 15 17:50:00 2019
user hedrick, KRB5CCNAME=KCM:
klist -l
clh@CS.RUTGERS.EDU API:1003:4 Aug 15 15:51:22 2019
hedrick@CS.RUTGERS.EDU API:1003:3 Aug 15 17:10:40 2019
sudo su - root, klist -l
— nothing —
I tried klist -c with various arguments, such as KCM:, API:, the same with 1003 and 1003:3. It can’t see anything.
Using MIT klist doesn’t change anything, except that API: is an invalid type.
The reason I did "sudo su - root" is that sudo changes effective but not real uid. So “sudo klist” will show the user’s caches, because it still has the user’s real UID.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
