krb5 library missing functions for collections

Charles Hedrick hedrick at rutgers.edu
Thu Aug 15 10:01:15 EDT 2019


On Jul 30, 2019, at 4:17 AM, Jakub Hrozek <jhrozek at redhat.com> wrote:
> 
> On Mon, Jul 29, 2019 at 02:35:40PM -0400, Robbie Harwood wrote:
>> Greg Hudson <ghudson at 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 at CS.RUTGERS.EDU   API:51BC99CE-119B-42AC-8021-2B5DDE644A42   Aug 15 17:50:00 2019

user hedrick, KRB5CCNAME=KCM:

klist -l

 clh at CS.RUTGERS.EDU       API:1003:4     Aug 15 15:51:22 2019
 hedrick at 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.








More information about the Kerberos mailing list