gss_pname_to_uid: is that the right interface

[Simo Sorce]

On Thu, 2011-09-22 at 02:08 -0700, Danilo Almeida wrote:
> Sam wrote:
> > We introduced a new interface that converts a GSS-API name resulting
> > from authentication to a uid.
> ...
> > I wonder whether we'd be better off with [...] gss_localname
> 
> Simo wrote:
> > 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.
> 
> Nico wrote:
> > 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.
> 
> Sam wrote:
> > Provide an authorization plugin that calls out to sssd and attaches a
> > local name attribute to the name.
> 
> My familiarity with this area is pretty limited, but some of what I read
> raised some questions and potential concerns, so I wanted to follow up.  If
> I am misunderstanding the discussion, please let me know.
> 
> 1) Does sssd refer to http://fedoraproject.org/wiki/Features/SSSD?

Yes

> 2) What are the desired use cases for gss_pname_to_uid and gss_localname?
> (Are they really about getting a uid and local username?)

Yes

> 3) Is gss_localname effectively the equivalent of doing a
> gss_get_name_attribute with some well-known attribute for the local
> udername?
> 
> Adding OS authorization notions such as username or uid as a new calls into
> GSSAPI seems like a really bad idea.  My understanding is that
> gss_get_name_attribute() is supposed to avoid having to do that.  Any such
> info could be derived from the security context by an application
> introspecting into the security context (potentially via some helper library
> code that is not part of the GSS API implementation calling into
> gss_get_name_attribute or other GSS calls).  Alternatively, an authdata
> plugin could just add the OS-specific info as an attribute (potentially
> based on other attributes added by other authdata plugins) so that the
> application can just use gss_get_name_attribute() to get the new attribute
> that has the new auth info.  I think that matches what Nico and Sam have
> stated.

Yes we want a OS specific plugin to return this kind of datat I think.
That's why I want to plug SSSD in there.

Simo.

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