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&data=02%7C01%7CJoseph.Jeffries%40minnstate.e
>> du%7C128aced6b4f3435c93f208d721896996%7C5011c7c60ab446ab9ef4fae74a921
>> a7f%7C0%7C0%7C637014746400029083&sdata=4VV34uh1EkcjCJJsv96TqSfbvy
>> %2F5hVvxRTfzEzAvnjI%3D&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&data=02%7C01%7CJoseph.Jeffries%40minnstate
>> .edu%7C128aced6b4f3435c93f208d721896996%7C5011c7c60ab446ab9ef4fae74a9
>> 21a7f%7C0%7C0%7C637014746400029083&sdata=cX5L%2BTX4P6ef0SkhcOmqZn
>> Df%2FH5APSZsSEwElRhmyro%3D&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&data=02
> %7C01%7CJoseph.Jeffries%40minnstate.edu%7C128aced6b4f3435c93f208d72189
> 6996%7C5011c7c60ab446ab9ef4fae74a921a7f%7C0%7C0%7C637014746400029083&a
> mp;sdata=rdKzxATrhL73S8AqCU3h%2Fc4XpIDG1MRPwNf7ZiivZjc%3D&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&data=02%7C01%7CJoseph.Jeffries%40minnstate.edu%7C128aced6b4f3435c93f208d721896996%7C5011c7c60ab446ab9ef4fae74a921a7f%7C0%7C0%7C637014746400029083&sdata=TavtvLk17NqePuQ4nnewEcvpXOyrJGkHcFpFga2oxsU%3D&reserved=0
More information about the Kerberos
mailing list