krb5 library missing functions for collections

[Greg Hudson]

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.

> I get the same results on my Mac if I use a Macports port of MIT Kerberos. With the builtin utilies I can’t make KCM work at all.

That's a little surprising to me.  My read of the OSX Heimdal code
suggests that it should allow "KCM:" as well as "API:".

> KEYRING:persistent:UID is a collection. All actual caches are KEYRING:persistent:UID:stuff, so there’s no ambiguity.
> 
> There are other formats for KEYRING for per-process, etc., but as far as I know they’re not used and would be pretty hard to use except for inside a specific application.

The uid in "KEYRING:persistent" is optional (the process euid is used
implicitly), and the "session" and "user" forms (which do not have uids)
can be used across applications.

[Regarding OSX native utilities:]
> 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.

The Heimdal kinit is a bit more aggressive than the MIT kinit in using a
collection when the ccache type supports it.  See
http://kerberos.996246.n3.nabble.com/KRB5CCNAME-new-semantics-under-Maverick-td40272.html
for some discussion of that.

> So we have behavior that is specific not just to the OS, but which libraries are in use. Wonderful.

Heimdal and MIT krb5 only promise to implement the same network
protocol, not to have identical behavior.  The OS X fork of Heimdal also
has significant behavior differences from upstream Heimdal.

Taking a step back: I'm guessing the use case here includes NFS.  The
architecture of Linux NFS and of Kerberos ccaches have unfortunately
never fit together in a very satisfactory way.  The NFS userspace daemon
wants to know what credentials are available to a user, knowing only its
uid, while credential cache types are typically designed to provide
flexibly named containers, not necessarily restricted to a single place
per user or even restricted to use by one user.

AFS, by contrast, has a mechanism (aklog) for userspace to tell the
kernel what credentials to use.  A single euid can have different
process groups (called PAGs) using different credentials.  This design
isn't perfect either, as the login and credential refresh systems need
enough hooks to know to re-run aklog (or unlog on credential destruction).