Re: krb5 library missing functions for collections
ugh. rpc.gssd reads root’s .k5identity file. If I put my principal in /.k5identity, things work. So a plugin would probably work. But it looks like a bug that should be fixed. > On Jul 23, 2019, at 10:09 AM, Charles Hedrick wrote: > > Maybe there’s a path through the code that I didn’t find. But it ends up > failing if the credential isn’t username@DOMAIN. There’s an explicit test. I > don’t see why it couldn't specify that in the first place. > > I think if you want a local user joe to access NFS as jdoe@REALM, you’d want > to set up that mapping somewhere. I haven’t checked this in the code, but I’d > expect it in a krb5.conf mapping, .k5identity, and/or idmap. I doubt you want > NFS to use whatever random ticket may be in the default cache for the uid > making the access. As far as I can tell it doesn’t actually do that now. > >> On Jul 23, 2019, at 9:35 AM, Simo Sorce wrote: >> >> On Mon, 2019-07-22 at 20:10 +, Charles Hedrick wrote: >>> The problem is that the code in rpc.gssd works as followers: >>> >>> * get the default credential from the collection >>> * fail unless it’s username@DOMAIN >>> >>> If you replace the initial step by code telling it explicitly to get >>> username@DOMAIN then it works just fine, assuming that the user >>> actually has such a credential. Which they will. GSSAPI is perfectly >>> capable of looking for a specific credential if you tell it to. It’s >>> just that the code doesn’t do it that way. To avoid building my own >>> copy of rpc.gssd, I use a loadable library to interpose code around >>> GSSAPI that supplies the right argument. >> >> rpc.gssd does this because it cannot know what the right credential >> name is in all situations. >> >> In very controlled environments it is indeed username + @REALM and the >> realm is known, but in other cases it is not. >> For example a personal laptop where the username is 'joe' and no >> default realm is set and someone doing kinit jdoe@WORK.REALM then >> walking into an NFS mount. >> >> I guess the nfs-utils folks may accept a patch to rpc.gssd where an >> option can be given to assume a specific form for the user's principal >> name to look for, but that can't be the default as it would break >> current uses. >> >> HTH, >> Simo. >> >> -- >> Simo Sorce >> RHEL Crypto Team >> Red Hat, Inc >> >> >> >> > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb5 library missing functions for collections
On Tue, 2019-07-23 at 14:09 +, Charles Hedrick wrote: > Maybe there’s a path through the code that I didn’t find. But it ends > up failing if the credential isn’t username@DOMAIN. There’s an > explicit test. I don’t see why it couldn't specify that in the first > place. > > I think if you want a local user joe to access NFS as jdoe@REALM, > you’d want to set up that mapping somewhere. I haven’t checked this > in the code, but I’d expect it in a krb5.conf mapping, .k5identity, > and/or idmap. I doubt you want NFS to use whatever random ticket may > be in the default cache for the uid making the access. As far as I > can tell it doesn’t actually do that now. Actually this is how NFS is supposed to work, it will pick the first valid credential, but it is possible a later change broke it. .k5identity is also an option but as a way to select a non-default principal, if you have only one krbtgt regardless of what it is I expect an NFS mount to try to use that credential. Simo. > > On Jul 23, 2019, at 9:35 AM, Simo Sorce wrote: > > > > On Mon, 2019-07-22 at 20:10 +, Charles Hedrick wrote: > > > The problem is that the code in rpc.gssd works as followers: > > > > > > * get the default credential from the collection > > > * fail unless it’s username@DOMAIN > > > > > > If you replace the initial step by code telling it explicitly to get > > > username@DOMAIN then it works just fine, assuming that the user > > > actually has such a credential. Which they will. GSSAPI is perfectly > > > capable of looking for a specific credential if you tell it to. It’s > > > just that the code doesn’t do it that way. To avoid building my own > > > copy of rpc.gssd, I use a loadable library to interpose code around > > > GSSAPI that supplies the right argument. > > > > rpc.gssd does this because it cannot know what the right credential > > name is in all situations. > > > > In very controlled environments it is indeed username + @REALM and the > > realm is known, but in other cases it is not. > > For example a personal laptop where the username is 'joe' and no > > default realm is set and someone doing kinit jdoe@WORK.REALM then > > walking into an NFS mount. > > > > I guess the nfs-utils folks may accept a patch to rpc.gssd where an > > option can be given to assume a specific form for the user's principal > > name to look for, but that can't be the default as it would break > > current uses. > > > > HTH, > > Simo. > > > > -- > > Simo Sorce > > RHEL Crypto Team > > Red Hat, Inc > > > > > > > > > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb5 library missing functions for collections
this is worse than it looks. Documentation says that GSSAPI will obey .k5identity. That’s the right solution for you situation of the laptop user with a different username. The problem is that there’s no system-wide equivalent of .k5identity. My code causes problems, because in specifying a particular principle it bypasses .k5identity. But for the normal case we don’t want every user to have to specify a .k5identity. I suspect the right thing for me to do is rather than hack rpc.gssd, supply a cc_select plugin to make the obvious selection for service=nfs. But I claim this ought to be the default. I shouldn’t have to do C coding to make it happen. > On Jul 23, 2019, at 10:09 AM, Charles Hedrick wrote: > > Maybe there’s a path through the code that I didn’t find. But it ends up > failing if the credential isn’t username@DOMAIN. There’s an explicit test. I > don’t see why it couldn't specify that in the first place. > > I think if you want a local user joe to access NFS as jdoe@REALM, you’d want > to set up that mapping somewhere. I haven’t checked this in the code, but I’d > expect it in a krb5.conf mapping, .k5identity, and/or idmap. I doubt you want > NFS to use whatever random ticket may be in the default cache for the uid > making the access. As far as I can tell it doesn’t actually do that now. > >> On Jul 23, 2019, at 9:35 AM, Simo Sorce wrote: >> >> On Mon, 2019-07-22 at 20:10 +, Charles Hedrick wrote: >>> The problem is that the code in rpc.gssd works as followers: >>> >>> * get the default credential from the collection >>> * fail unless it’s username@DOMAIN >>> >>> If you replace the initial step by code telling it explicitly to get >>> username@DOMAIN then it works just fine, assuming that the user >>> actually has such a credential. Which they will. GSSAPI is perfectly >>> capable of looking for a specific credential if you tell it to. It’s >>> just that the code doesn’t do it that way. To avoid building my own >>> copy of rpc.gssd, I use a loadable library to interpose code around >>> GSSAPI that supplies the right argument. >> >> rpc.gssd does this because it cannot know what the right credential >> name is in all situations. >> >> In very controlled environments it is indeed username + @REALM and the >> realm is known, but in other cases it is not. >> For example a personal laptop where the username is 'joe' and no >> default realm is set and someone doing kinit jdoe@WORK.REALM then >> walking into an NFS mount. >> >> I guess the nfs-utils folks may accept a patch to rpc.gssd where an >> option can be given to assume a specific form for the user's principal >> name to look for, but that can't be the default as it would break >> current uses. >> >> HTH, >> Simo. >> >> -- >> Simo Sorce >> RHEL Crypto Team >> Red Hat, Inc >> >> >> >> > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb5 library missing functions for collections
Maybe there’s a path through the code that I didn’t find. But it ends up failing if the credential isn’t username@DOMAIN. There’s an explicit test. I don’t see why it couldn't specify that in the first place. I think if you want a local user joe to access NFS as jdoe@REALM, you’d want to set up that mapping somewhere. I haven’t checked this in the code, but I’d expect it in a krb5.conf mapping, .k5identity, and/or idmap. I doubt you want NFS to use whatever random ticket may be in the default cache for the uid making the access. As far as I can tell it doesn’t actually do that now. > On Jul 23, 2019, at 9:35 AM, Simo Sorce wrote: > > On Mon, 2019-07-22 at 20:10 +, Charles Hedrick wrote: >> The problem is that the code in rpc.gssd works as followers: >> >> * get the default credential from the collection >> * fail unless it’s username@DOMAIN >> >> If you replace the initial step by code telling it explicitly to get >> username@DOMAIN then it works just fine, assuming that the user >> actually has such a credential. Which they will. GSSAPI is perfectly >> capable of looking for a specific credential if you tell it to. It’s >> just that the code doesn’t do it that way. To avoid building my own >> copy of rpc.gssd, I use a loadable library to interpose code around >> GSSAPI that supplies the right argument. > > rpc.gssd does this because it cannot know what the right credential > name is in all situations. > > In very controlled environments it is indeed username + @REALM and the > realm is known, but in other cases it is not. > For example a personal laptop where the username is 'joe' and no > default realm is set and someone doing kinit jdoe@WORK.REALM then > walking into an NFS mount. > > I guess the nfs-utils folks may accept a patch to rpc.gssd where an > option can be given to assume a specific form for the user's principal > name to look for, but that can't be the default as it would break > current uses. > > HTH, > Simo. > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb5 library missing functions for collections
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 * c...@cs.rutgers.edu KCM:1003:4 Jul 23 17:18:08 2019 c...@cs.rutgers.edu API:1003:4 Jul 23 17:18:08 2019 hedr...@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 c...@cs.rutgers.edu API:1003:4 Jul 23 17:18:08 2019 hedr...@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: * c...@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 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 ":" 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
Re: krb5 library missing functions for collections
On Mon, 2019-07-22 at 20:10 +, Charles Hedrick wrote: > The problem is that the code in rpc.gssd works as followers: > > * get the default credential from the collection > * fail unless it’s username@DOMAIN > > If you replace the initial step by code telling it explicitly to get > username@DOMAIN then it works just fine, assuming that the user > actually has such a credential. Which they will. GSSAPI is perfectly > capable of looking for a specific credential if you tell it to. It’s > just that the code doesn’t do it that way. To avoid building my own > copy of rpc.gssd, I use a loadable library to interpose code around > GSSAPI that supplies the right argument. rpc.gssd does this because it cannot know what the right credential name is in all situations. In very controlled environments it is indeed username + @REALM and the realm is known, but in other cases it is not. For example a personal laptop where the username is 'joe' and no default realm is set and someone doing kinit jdoe@WORK.REALM then walking into an NFS mount. I guess the nfs-utils folks may accept a patch to rpc.gssd where an option can be given to assume a specific form for the user's principal name to look for, but that can't be the default as it would break current uses. HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
