Some more testing on MacOS. With the native Mac utilities, it uses credential type API:
It appears that if you set KRB5CCNAME to API or API:uid, it behaves the same way: If creates new unique names like API:027B19DC-01E6-4610-9300-7E3E1DFF706A. Even if I set KRB5CCNAME to a specific cache, if I kinit a different user, it creates a new cache name. So it seems like API: followed by nothing or anything is the whole collection in contexts where a collection will work. But it still behaves like API: is user-specific, even though the name-space for actual caches is probably global. Weird. If you use ported MIT utilities they behave like Redhat, and use KCM rather than API. KCM: is a collection of my caches just like API: is. But KCM:foo is now a specific cache. So we have behavior that is specific not just to the OS, but which libraries are in use. Wonderful. > On Jul 22, 2019, at 1:00 PM, Greg Hudson <ghud...@mit.edu> wrote: > > On 7/22/19 11:16 AM, Charles Hedrick wrote: >> I was surprised to find the methods to do these things aren’t present. >> Here’s what I’ve defined: > > Some of this is covered in > https://k5wiki.kerberos.org/wiki/Projects/Credential_cache_collection_improvements > (which unfortunately has not been worked on in quite a while), but not > all of it. > >> The first two have uid arguments because of KCM. Every other cache type >> allows you to determine unambiguously what user it’s associated with. > > By my reading, KEYRING also doesn't generally include the uid in the name. > >> This oddity of KCM is really irritating. It means you have to do setruid >> every time you want to deal with a collection from a daemon, since otherwise >> the name is ambiguous. > > The KCM daemon's namespace is machine-global, not uid-specific, and I > don't think doing setruid() would be visible to the daemon anyway (it > should see the euid of the client, not the ruid). ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos