gss_pname_to_uid: is that the right interface
nico at cryptonector.com
Tue Sep 20 22:35:24 EDT 2011
On Tue, Sep 20, 2011 at 5:50 PM, Simo Sorce <simo at redhat.com> wrote:
> On Tue, 2011-09-20 at 16:11 -0500, Nico Williams wrote:
>> I think this one's really just for compatibility with Solaris. I
>> agree that putting UIDs in any of these APIs is a bad idea, but I'm
>> not sure that the SSSD problem wouldn't exist for your proposed
>> variant. If the problem for SSSD is one of timing, why couldn't that
>> problem exist for *any* GSS version of krb5_aname_to_lname()?
>> Any timing issues w.r.t. SSSD should be documented by RedHat and/or
>> the mechanism implementor/vendor.
> We have an issue with OpenSSH doing getpwnam() before SSSD has a chance
> of getting its hands on the MS-PAC (or in future the PAD with the POSIX
> attributes). So avoiding getpw*() calss is a good idea.
Note that the same could have been said of PAM. IIRC I did some work
on SunSSH to delay getpwnam() calls as much as possible (but it's been
seven or eight years now).
> If krb5_aname_to_lname() is implemented by using getpw() calls it has
> the same kind of issues, but it doesn't need to. mapping principal name
> to local name usually is not done through the NSS interface, while
> getting the uid can only be done through that interface.
aname2lname() need not need any getpw*() calls, but who knows what a
plugin might need.
Furthermore, what if you need to do self-credentialed LDAP or LSA
lookups before you can complete a principal name to username mapping?
It's conceivable. And if aname2lname() were pluggable, all the more
What's bad about gss_pname_to_uid() is that it deals in UIDs, thus is
inherently not portable. A gss_aname_to_lname() would be more
portable, but could still conceivably suffer from timing issues.
What would be best, IMO, is to have a way to pass the gss_name_t (and
any delegated credentials, and maybe even the security context) to
SSSD, then get the username from SSSD.
More information about the krbdev