gss_pname_to_uid: is that the right interface

[Simo Sorce]

On Tue, 2011-09-20 at 21:35 -0500, Nico Williams wrote:
> 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).

There are similar patches for OpenSSH, will see when we can put them
upstream.

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

True, the badness of the interface is indeed in exposing non portable
information, that was a given in my mind. I was just pointing out
additional issues that make it bad even in a unix environment.

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

This is in fact, something I would like to see, and have already planned
to take a stab into seeing how difficult it is to plug this in.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York