[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