krb5 library missing functions for collections

[Charles Hedrick]

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 <ghudson at 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).