FW: krb5 library missing functions for collections

Jeffries, Joseph L Joseph.Jeffries at minnstate.edu
Thu Aug 15 10:09:12 EDT 2019


Please remove me from this list.

Thanks!

-----Original Message-----
From: kerberos-bounces at mit.edu <kerberos-bounces at mit.edu> On Behalf Of Charles Hedrick
Sent: Thursday, August 15, 2019 9:01 AM
To: Jakub Hrozek <jhrozek at redhat.com>
Cc: kerberos at mit.edu
Subject: Re: krb5 library missing functions for collections

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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>> hub.com%2FSSSD%2Fsssd%2Fblob%2Fmaster%2Fsrc%2Fresponder%2Fkcm%2Fkcmsr
>> v_ccache.h%23L75-L80&amp;data=02%7C01%7CJoseph.Jeffries%40minnstate.e
>> du%7C128aced6b4f3435c93f208d721896996%7C5011c7c60ab446ab9ef4fae74a921
>> a7f%7C0%7C0%7C637014746400029083&amp;sdata=4VV34uh1EkcjCJJsv96TqSfbvy
>> %2F5hVvxRTfzEzAvnjI%3D&amp;reserved=0
>> and
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>> hub.com%2FSSSD%2Fsssd%2Fblob%2Fmaster%2Fsrc%2Fresponder%2Fkcm%2Fkcmsr
>> v_ccache.h%23L144-L156&amp;data=02%7C01%7CJoseph.Jeffries%40minnstate
>> .edu%7C128aced6b4f3435c93f208d721896996%7C5011c7c60ab446ab9ef4fae74a9
>> 21a7f%7C0%7C0%7C637014746400029083&amp;sdata=cX5L%2BTX4P6ef0SkhcOmqZn
>> Df%2FH5APSZsSEwElRhmyro%3D&amp;reserved=0
> 
> Hrm, maybe that comment is outdated. I thought, after discussing this 
> with Greg some time ago:
>    
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fkrb5%2Fkrb5%2Fpull%2F557%23issuecomment-254834623&amp;data=02
> %7C01%7CJoseph.Jeffries%40minnstate.edu%7C128aced6b4f3435c93f208d72189
> 6996%7C5011c7c60ab446ab9ef4fae74a921a7f%7C0%7C0%7C637014746400029083&a
> mp;sdata=rdKzxATrhL73S8AqCU3h%2Fc4XpIDG1MRPwNf7ZiivZjc%3D&amp;reserved
> =0 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.






________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fkerberos&amp;data=02%7C01%7CJoseph.Jeffries%40minnstate.edu%7C128aced6b4f3435c93f208d721896996%7C5011c7c60ab446ab9ef4fae74a921a7f%7C0%7C0%7C637014746400029083&amp;sdata=TavtvLk17NqePuQ4nnewEcvpXOyrJGkHcFpFga2oxsU%3D&amp;reserved=0



More information about the Kerberos mailing list