[SSSD] [PATCHES][PRELIMINARY] Support for multiple LDAP search bases

Jan Zelený jzeleny at redhat.com
Mon Sep 26 13:10:59 UTC 2011


> These patches add support for multiple search bases for users and groups
> in non-enumeration mode. I want to get these out for review before I
> start working on the enumeration support, so if there are major issues
> they will be found before I put in a lot more work.
> 
> Some notes: There is no patch adding multiple search base support for
> group lookups in RFC2307bis because it's meaningless right now. Since
> the group memberships are direct DNs, we do all of our searches as base
> searches, ignoring group_search_base. There is a separate ticket,
> https://fedorahosted.org/sssd/ticket/960 that will need to address this,
> taking advantage of the multiple search base features.
> 
> Also, while working through this, I opened
> https://fedorahosted.org/sssd/ticket/1006 as I noticed that we are using
> far too many separate transactions while processing RFC2307bis (which is
> likely the cause of the extreme slowdown that some of our users were
> reporting with AD).
> 
> Thank you, and please review promptly.
> 
> 
> Patch 0001: Remove some unused options in a struct

Ack

> Patch 0002: Fix size return for split_on_separator()
> It was returning the size of the array, rather than the number of
> elements. (The array was NULL-terminated). This argument was only
> used in one place that was actually working around this odd return
> value.

Ack

> Patch 0003: Make sdap_get_id_specific_filter() more strict
> Just makes it take const char * instead of char *.

Ack

> Patch 0004: Add parser for multiple search bases
> As discussed on the list, this will the ldap_*_search_base options in
> the form of:
> search_base[?scope?[filter][?search_base?scope?[filter]]*]
> This is backwards-compatible (just use a search base)

Why haven't you used the for cycle to parse search bases? Personally I'd 
prefer it that way, but I guess it is nothing wrong to do it this way either. 
Other than that the patch is fine.

> Patch 0005: Add support for multiple search bases for users
> 
> Patch 0006: Add support for multiple search bases for netgroups
> 
> Patch 0007: Add support for multiple search bases for RFC2307 groups
> 
> Patch 0008: Add support for multiple search bases for initgroups (user
> portion)

Ack to all four

> Patch 0009: Add support for multiple search bases for initgroups
> (RFC2307 group portion)

Is this the correct behavior? I mean if we find user, is it correct to look for 
for its initgroups in other search bases than the one we found the user in? It 
doesn't seem right to me.

> Patch 0010: Add support for multiple search bases for initgroups
> (RFC2307 group portion)
> This patch I'm not 100% sure of. It may need more processing. With
> RFC2307, it was safe to have duplicate groups in the list, because only
> the group name is important (and we guarantee that the name list has
> only unique values before saving it). With RFC2307bis, I'm not sure if
> it's safe to add two groups that may have the same name. Comments
> welcome.

The same as for 0009, I didn't go through the entire patch yet, more comments 
might come up

> Patch 0011: Temporary patch that just disallows the use of multiple
> search bases when enumeration mode is turned on. We can drop this patch
> when the enumeration support is available.

Ack

Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110926/9468a491/attachment.sig>


More information about the sssd-devel mailing list