389-ds-base

Clone
Source Code
GIT

#50678 Issue 50677 - Map subtree searches with NULL base to default naming context
Closed 3 years ago by spichugi. Opened 4 years ago by mreynolds.
mreynolds/389-ds-base issue50677  into  master

file modified
+11 -2 
@@ -90,7 +90,7 @@ 
 

  

      /* baseObject, scope, derefAliases, sizelimit, timelimit, attrsOnly */
 

      if (ber_scanf(ber, "{aiiiib", &rawbase, &scope, &deref, &sizelimit, &timelimit, &attrsonly) == LBER_ERROR) {
 

-         slapi_ch_free((void **)&rawbase);
 

+         slapi_ch_free_string(&rawbase);
 

          log_search_access(pb, "???", -1, "???", "decoding error");
 

          send_ldap_result(pb, LDAP_PROTOCOL_ERROR, NULL, NULL, 0, NULL);
 

          return;
 
@@ -106,11 +106,20 @@ 
 

                                         rawbase ? rawbase : "", "strict: invalid dn");
 

              send_ldap_result(pb, LDAP_INVALID_DN_SYNTAX,
 

                               NULL, "invalid dn", 0, NULL);
 

-             slapi_ch_free((void **)&rawbase);
 

+             slapi_ch_free_string(&rawbase);
 

              return;
 

          }
 

      }
 

  

+     if (rawbase && strlen(rawbase) == 0 && scope != LDAP_SCOPE_BASE) {

I don't see anything wrong with this code, but how do you trigger this condition? LDAP_SCOPE_BASE is -b "", which is a zero len string, so how do you then get to this here? Through not providing a -b? 

+         /* This is not a Root DSE search, so map it to the default naming context */
 

+         const char *default_basedn = config_get_default_naming_context();
 

+         if (default_basedn) {
 

+             slapi_ch_free_string(&rawbase);
 

+             rawbase = slapi_ch_strdup(default_basedn);
 

+         }
 

+     }
 

+ 

      /* If anonymous access is only allowed for searching the root DSE,
 

       * we need to reject any other anonymous search attempts. */
 

      if ((slapi_sdn_get_dn(&(operation->o_sdn)) == NULL) &&

Description:

The Root DSE entry is retreived by using a empty/NULL search base, and a
search scope of "BASE". According to the RFCs these are the exact requirements
for returning the Root DSE, but it does not dictate what you must do if
a different search scope is used. In DS we will return NO_SUCH_OBJECT if
the scope is ONE or SUBTREE. In AD it will use the default suffix in this
case.

To be more compatible AD, specifically global catalog, 389 should also return
the default naming context for a non-Root DSE search(a NULL suffix with a
scope of ONE, or SUBTREE).

relates: https://pagure.io/389-ds-base/issue/50677

I don't see anything wrong with this code, but how do you trigger this condition? LDAP_SCOPE_BASE is -b "", which is a zero len string, so how do you then get to this here? Through not providing a -b?

Well ldapsearch requires -b. When requesting the root dse entry you must use this syntax:

ldapsearch -b "" -s base

If you don't use "-s base" it defaults to "subtree" and it would say "no such object" as Root DSE can only be returned if the scope is set to base. Now with this patch if you use a scope of "one" or "subtree", instead of "no such object", it will try use the default naming context instead. This is what AD does, and I see no reason why we shouldn't do it as well.

So this returns the Root DSE entry

ldapsearch -b "" -s base

This below returns the default naming context (instead of no such object):

ldapsearch -b "" -s sub

"This is what AD does"

Not that I'm opposed to this, I think AD does some great stuff, but is there some other motivation for this change that I'm not aware of?

Anyway, ack from me, but curious about the change ....

"This is what AD does"
Not that I'm opposed to this, I think AD does some great stuff, but is there some other motivation for this change that I'm not aware of?
Anyway, ack from me, but curious about the change ....

Sure, this is part of our Global Catalog effort with IDM. From what I understand this was the last remaining piece to get it working! @abbra explained this a bit in the ticket 50677 description.

rebased onto 5e338e9
4 years ago

Pull-Request has been merged by mreynolds
4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3733

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.

Pull-Request has been closed by spichugi
3 years ago
Metadata
None
No Tags
Changes Summary 1
+11 -2
file changed
ldap/servers/slapd/search.c
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.