Please remove me from this list. Thanks!
-----Original Message----- From: kerberos-boun...@mit.edu <kerberos-boun...@mit.edu> On Behalf Of Charles Hedrick Sent: Thursday, August 15, 2019 9:01 AM To: Jakub Hrozek <jhro...@redhat.com> Cc: kerberos@mit.edu Subject: Re: krb5 library missing functions for collections On Jul 30, 2019, at 4:17 AM, Jakub Hrozek <jhro...@redhat.com> wrote: > > On Mon, Jul 29, 2019 at 02:35:40PM -0400, Robbie Harwood wrote: >> Greg Hudson <ghud...@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 * c...@cs.rutgers.edu API:51BC99CE-119B-42AC-8021-2B5DDE644A42 Aug 15 17:50:00 2019 user hedrick, KRB5CCNAME=KCM: klist -l c...@cs.rutgers.edu API:1003:4 Aug 15 15:51:22 2019 hedr...@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://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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
