[SSSD] [PATCHES] Handle nested groups in RFC2307bis (sssd-1-2)

Stephen Gallagher sgallagh at redhat.com
Thu Oct 7 13:18:48 UTC 2010


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

On 10/07/2010 09:14 AM, Jakub Hrozek wrote:
> On 10/06/2010 05:48 PM, Stephen Gallagher wrote:
>> These patches apply atop Jakub's "Fix initgroup processing for RFC2307
>> (sssd-1.2)" patches.
> 
>> Patch 0002: Add option to limit nested groups
> 
> 
> Is the ldap_memberof_support option going to be used in any of the later
> patches? It doesn't seem to be used in 0003. With IPA backend it was
> also causing some weirdness (I guess b/c the indexes are out of sync):

Whoops, I guess I missed a few spots. I meant to remove references to
that option, because we're not using it for now.

> 
> [sssd[be[IDM.LAB.BOS.REDHAT.COM]]] [_dp_opt_get_int] (0):
> [sdap_nested_group_process_send] Requested type 'Number' for option
> 'ldap_memberof_support' but value is of type 'String'!
> 
> ldap_group_nesting_level is not present in documentation or the
> SSSDConfigAPI (the latter is probably OK at this point since the only
> user is authconfig).
> 
>> Patch 0003: Handle nested groups in RFC2307bis
> 
>> This first approach handles the non-optimized "pure" RFC2307bis
>> case. It recursively calls into nested groups until it it has
>> found them all or hits the pre-defined nesting limit.
> 
>> It then saves all member users first, then all groups to the sysdb
> 
> 
>> This patch only handles the general case of RFC2307bis nested groups. It
>> contains no optimizations for memberOf implementations. Given that we
>> have time constraints, this patch should handle all implementations of
>> RFC2307bis correctly (if not high-performance).
> 
>> Support for partial (AD) and complete (IPA) memberOf will be added to
>> the master branch later.
> 
> 
>> Still to do: initgroups for RFC2307bis using Jakub's fake groups.
> 
> 
> So far I only read the patch, not tested much, I think it looks
> good..I'll provide more feedback after I test it :-)
> 
> I only have one question so far: why the memory hierarchy between
> user_hash and group_hash in sdap_get_groups_process(), and then using
> group_hash as mem_ctx of sdap_nested_group_process_send()?

Just for simplicity of memory management. user_hash and group_hash are
related because it makes it easier to clean up on an error case (just
free the top-most value)

However, I got the memory context of sdap_nested_group_process_send
backwards, I think. I should really be stealing the user_hash and
group_hash onto the subreq so that they are always valid while the
request is running and are automatically cleaned up when it ends.

I'll send an updated patch a little later.

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

iEYEARECAAYFAkytyLgACgkQeiVVYja6o6ONEgCfUq719kQlDb/0I9n9AuAw8Mii
so4An0bHxmZZby3IREA5Jw0/77fEy4vM
=qPVb
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list