gss_pname_to_uid: is that the right interface

[Nico Williams]

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
so.

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.

Nico
--