<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 09/12/2011 08:41 AM, Stephen Gallagher wrote:
    <blockquote
      cite="mid:1315831280.2367.4.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap="">I'm starting to implement the "multiple search bases" feature requested
in <a class="moz-txt-link-freetext" href="https://fedorahosted.org/sssd/ticket/868">https://fedorahosted.org/sssd/ticket/868</a>

I want a bit of input on my design (Original text at
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/sssd/wiki/DesignDocs/MultipleSearchBases">https://fedorahosted.org/sssd/wiki/DesignDocs/MultipleSearchBases</a>

I don't expect there to be any disagreements about the individual lookup
case, but I'm not sure if there will be contention around the
enumeration decisions. Recommendations are welcome.


== Purpose ==

Some deployments use search bases to limit or extend the set of users
and groups visible to a system.

One common example is for applications granting access only to users in
a hard-coded group name. In this case, the group search base would
generally be set differently for each machine running this application.
Other machines running the same application providing access to other
users would receive a different "view" of LDAP through the use of search
bases.

== Expected Behavior ==

=== Individual Lookups ===

For targeted lookups (e.g. getpwuid(), getgrnam()) we should try each of
the search bases in order until one of them returns the entry we are
looking for, or we have exhausted all of the search bases. Each search
will be performed with the search scope provided.

=== Enumeration ===
For enumeration, we will need to iterate through ALL search bases to
retrieve users, groups, etc. For each search base, we need to examine
each entry retrieved and compare it against the entries received from
earlier search bases. If there are conflicts, we will discard the
conflicting value from the later search base. (Therefore the entry in
the earlier search bases will always win.
</pre>
    </blockquote>
    <br>
    I am not sure we should pre-match anything and sort duplicates.<br>
    We should put fetched data into the cache right away as a result of
    one search and then do the second search following the same logic
    and so on.<br>
    If we encounter a duplicate i.e. a full duplicate of a user we just
    updated (same user) we should just skip it. If we find a collision
    meaning we found a user with same id but different name or vice
    verse (same with group) we should report and skip. This is a
    misconfiguration and admin should sort his domain out. <br>
    <br>
    <blockquote
      cite="mid:1315831280.2367.4.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap="">
== Implementation ==
We will extend the ldap_*_search_base options to support behavior
similar to that of nss_base_passwd and nss_base_group from nss-ldapd.
</pre>
    </blockquote>
    <br>
    Is it a literal * or it is a placeholder?<br>
    In either case I do not like an approach. IMO the key names should
    be predefined.<br>
    <br>
    May be use:<br>
    <br>
    ldap_search_base_multi = triplet, triplet, triplet<br>
    <br>
    <blockquote
      cite="mid:1315831280.2367.4.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap="">
The standard search base (ldap_search_base will be left alone as a
single value with scope "subtree".

The new ldap_*_search_base options will include a new delimiter, '?'. If
this is present, we will divide the string up into triples as follows:

search_base?scope?filter[?search_base?scope?filter...]

</pre>
    </blockquote>
    <br>
    Alternatively you can add sub sections to the ldap provider (we
    alread yuse this approach with domains and providers, I do not see
    why we should deviate in this case too)<br>
    <br>
    ldap_search_base_multi = section1, section2, section3<br>
    <br>
    [.../default/ldap_search/section1]<br>
    ldap_search_base = x<br>
    ldap_search_filter = y<br>
    ldap_search_scope = z<br>
    <br>
    [.../default/ldap_search/section2]<br>
    ldap_search_base = x<br>
    ldap_search_filter = y<br>
    ldap_search_scope = z<br>
    <br>
    <br>
    It will be easier to parse, more structured and readable and with
    such organization you can extend the current search filter leaving
    it (if specified) to be the first search filter to use.<br>
    In addition if the grammar validation is ever implemented we would
    be able to apply the rules to such config. If we go with the
    original proposal the ini validation would not be usable.<br>
    <br>
    <blockquote
      cite="mid:1315831280.2367.4.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap="">=== Parsing ===
We will split the input string on the '?' delimiter. If the resulting
array is exactly one, or is a multiple of three, we will continue.
Otherwise it will fail validation.

</pre>
    </blockquote>
    That would not be needed in the approach above.<br>
    <br>
    <blockquote
      cite="mid:1315831280.2367.4.camel@sgallagh520.bos.redhat.com"
      type="cite">
      <pre wrap="">The scope must be one of 'subtree', 'onelevel' or
'base' (case-insensitive).

The filter will be optional and may be a zero-length string. The filter
must be pre-sanitized and must pass filter validation with
ldb_parse_tree()
</pre>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/mailman/listinfo/sssd-devel">https://fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
<a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a>


</pre>
  </body>
</html>