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://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 * 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://mailman.mit.edu/mailman/listinfo/kerberos
