[SSSD] [RFC][PATCH] Add new getgrgid2(), getgrnam2() interfaces to glibc

Stephen Gallagher sgallagh at redhat.com
Tue Oct 19 13:59:21 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/19/2010 09:09 AM, Ralf Haferkamp wrote:

>> The net result is that we will report all of the users that belong in
>> a group, but we will not make additional requests to populate those
>> users unless they are directly requested.
>>
>> Yes, for groups that have many thousands of users, we may make a
>> single request that transfers a couple hundred kilobytes, but we do
>> not make subsequent requests for each of those users in turn.
>>
>> RFC2307bis servers require slightly more processing, as we need to
>> make multiple requests to LDAP if there are nested groups in play.
>> But we never make more requests than the configured nesting limit.
> I think your are mixing things up a bit. For RFC2307bis, even if nested 
> groups are not used (IIRC nested groups were never really part of 
> RFC2307bis), sssd still needs to make an LDAP lookup for every single 
> member to correctly populate the gr_mem attribute of the struct group, 
> you can't create any fake entries in the sssd cache for that (the fake 
> user approach only works with plain old RFC2307 groups).
> 

Sorry, you are correct. I forgot that we have to validate the DNs for
the RFC2307bis users. So for RFC2307bis, I suppose I can see some value
in this approach.

>>> Any comments on the API are welcome, including thoughts on how to
>>> make it more elegant. Originally, I wanted to implement it as
>>> gid_t getgidbyname(const char *name) etc., but I would have to redo
>>> some parts of the NSS infrastructure to easily allow returning gid_t
>>> instead of a struct.
>>>
>>> If there is a consensus that this is a good idea and Ulrich gives
>>> his blessing, I will of course extend the patch to be compatible
>>> with older NSS modules and add NIS support and nscd support.
>>
>> I'm really not sure what the value of this approach is. Realistically,
>> you're talking about creating an interface whose sole purpose is to
>> map GID<->groupname and nothing else?
> Yes.
>  
>> I'm not sure there's sufficient value in this approach, given that
>> it's possible as described above to limit the network requests. I
>> think it makes much more sense to guide the respective name-service
>> providers along the path of handling these requests more efficiently.
> That's the problem, for e.g. RFC2307bis this can't be done more 
> efficiently in a reliable manner (see the recent discussion around 
> getgrgid/getgrnam() on the sssd-devel list). So as most callers of 
> getgrnam/getgrgid don't use the member information anyways I think such 
> gid<->groupname mapping function could be quite useful. 
> 


My main concern with adding a new interface would be buy-in from all of
the assorted name-service providers (nss_nis, nss_ldap, etc.). Lets be
honest: even if we created this new interface, the most likely outcome
is that the libraries are just going to continue processing the way that
they do already, and then just reply with a limited subset of the results.

Creating the groups in our SSSD cache without including membership
information introduces integrity issues when we're dealing with offline
operation, for example. If access control for some application relies on
group membership, but our cache only has reference to the group and its
GID, without a list of members, then when we're offline and can't
request further information, we'll improperly deny access.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAky9pDkACgkQeiVVYja6o6OW0gCgovvx/tJCNI4x76zLquiCfvyp
wIUAoITswuJL1gICqpmu9QjBZXRnw6X8
=RR/e
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list