krb5 library missing functions for collections

[Charles Hedrick]

This matches the observed behavior. What you describe is internally a single address space, but from a user's point of view KCM: points to a different address space per user. It means there’s no unambiguous syntax for a root daemon to refer to a specific user’s collection. 

-------------------

MacOS seems to be an oddity. 

With no default ccname set, the Mac version of “klist -l” shows

* clh at CS.RUTGERS.EDU       KCM:1003:4     Jul 23 17:18:08 2019
  clh at CS.RUTGERS.EDU       API:1003:4     Jul 23 17:18:08 2019
  hedrick at CS.RUTGERS.EDU   API:1003:3     Jul 23 17:13:29 2019

klist (no argument) shows KCM:1003:4, as you’d expect.

However if I set KRB5CCNAME to either API: or KCM: I get

  clh at CS.RUTGERS.EDU       API:1003:4     Jul 23 17:18:08 2019
  hedrick at CS.RUTGERS.EDU   API:1003:3     Jul 23 17:13:29 2019

There’s no longer a selected cache, so klist with no argument says no cache. Setting KRB5CCNAME to API:1003 or KCM:1003 doesn’t help. I can’t find any non-blank setting of KRB5CCNAME that works, nor does doing an expect kswitch help.

Of course using the Macports utilities, things work fine. /usr/bin/ssh seems not to find credentials where the Macports one can, consistently with when /usr/bin/klist can find them.

As far as I can see, on the Mac with native utilities, root can still only see one user’s credentials. It sees the one matching its ruid.

Just to add to the fun, if no KRB5CCNAME is set, the native kinit produces this result:

* clh at CS.RUTGERS.EDU   API:3C09F9F9-6C7D-4D41-95CB-F053F4102C7A   Jul 23 17:58:11 2019

No indication of uid in the name at all. At least setting KRB5CCNAME to the specific cache works.



> On Jul 22, 2019, at 3:22 PM, Greg Hudson <ghudson at mit.edu> wrote:
> 
> 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).