gss_pname_to_uid: is that the right interface

Danilo Almeida dalmeida at MIT.EDU
Thu Sep 22 05:08:54 EDT 2011


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

- Danilo





More information about the krbdev mailing list