krb5 library missing functions for collections

[Charles Hedrick]

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.