gss_pname_to_uid: is that the right interface
simo at redhat.com
Thu Sep 22 09:49:23 EDT 2011
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?
> 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?)
> 3) Is gss_localname effectively the equivalent of doing a
> gss_get_name_attribute with some well-known attribute for the local
> 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
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 Sorce * Red Hat, Inc * New York
More information about the krbdev