Directory ApacheDS
  1. Directory ApacheDS
  2. DIRSERVER-1214

Searches done with an empty baseDN are not accepted, except for the rootDSE

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.3
    • Fix Version/s: 1.5.6
    • Component/s: None
    • Labels:
      None

      Description

      We can't do a search with an empty baseDN, when it's not specifically a rootDSE search (ie, (objectClass=*) and scope=OBJECT).

      We should consider that such a search is spreaded on all the partitions.

      This is not easy to implement without the nested partitions, as the current existing partitions are potentially stoed in different backends.

        Activity

        Hide
        Alex Karasulu added a comment -

        Can create an OR cursor over all partitions in the system to implement this btw. Should not be that hard.

        Show
        Alex Karasulu added a comment - Can create an OR cursor over all partitions in the system to implement this btw. Should not be that hard.
        Hide
        Emmanuel Lecharny added a comment -

        Let's fix that in 1.5.6

        Show
        Emmanuel Lecharny added a comment - Let's fix that in 1.5.6
        Hide
        Alex Karasulu added a comment -

        This really does not make protocol sense to me. Why? Well because the descent from the root DSE may not be one level down. Let me explain further: partitions can have a suffixes with more than one RDN component like dc=example,dc=com. When conducting search with anything other than base object scope this may become a problem since the returned set of entries will be disjoint (some will not have parents returned below the search base). This might mess up some clients.

        I think this issue should be closed and forgotten but we can implement it if need be. It's not that hard. However again it does not make protocol sense to me.

        Show
        Alex Karasulu added a comment - This really does not make protocol sense to me. Why? Well because the descent from the root DSE may not be one level down. Let me explain further: partitions can have a suffixes with more than one RDN component like dc=example,dc=com. When conducting search with anything other than base object scope this may become a problem since the returned set of entries will be disjoint (some will not have parents returned below the search base). This might mess up some clients. I think this issue should be closed and forgotten but we can implement it if need be. It's not that hard. However again it does not make protocol sense to me.
        Hide
        Emmanuel Lecharny added a comment -

        RFC 4512, par. 5.1 stipulates that "The root DSE SHALL NOT be included if the client performs a subtree search starting from the root." and that implicitely implies that you can do a search with an empty baseDN

        AFAICT, there is nothing specific about ONE_LEVEL search based on rootDSE, and NamingContexts, in the RFC. My interpretation is :
        The ONE level should start on NamingContext, not on the RDN forming their DN (ie, if a NamingContext is dc=example,dc=com, we should start at dc=example, not at dc=com).

        Show
        Emmanuel Lecharny added a comment - RFC 4512, par. 5.1 stipulates that "The root DSE SHALL NOT be included if the client performs a subtree search starting from the root." and that implicitely implies that you can do a search with an empty baseDN AFAICT, there is nothing specific about ONE_LEVEL search based on rootDSE, and NamingContexts, in the RFC. My interpretation is : The ONE level should start on NamingContext, not on the RDN forming their DN (ie, if a NamingContext is dc=example,dc=com, we should start at dc=example, not at dc=com).
        Hide
        Alex Karasulu added a comment -

        That is an implicit suggestion and I do think that subtree search may be performed but one level search would be really ugly. Think this way. If you do a one level search you are supposed to get everything subordinating to the base dn based on namespace. However because the namingContexts may have any number of RDNs greater than zero, then you cannot just returen each namingContent. You'll have to at least check if the namingContext suffix has 1 and only 1 namingContext before returning it.

        Show
        Alex Karasulu added a comment - That is an implicit suggestion and I do think that subtree search may be performed but one level search would be really ugly. Think this way. If you do a one level search you are supposed to get everything subordinating to the base dn based on namespace. However because the namingContexts may have any number of RDNs greater than zero, then you cannot just returen each namingContent. You'll have to at least check if the namingContext suffix has 1 and only 1 namingContext before returning it.
        Hide
        Emmanuel Lecharny added a comment -

        What if ONE_LEVEL search done on rootDSE simply return each context entry for all the namingContexts ? Pretty simple to implement , as we know that we are searching from root and that it's a ONE_LEVEL search...

        wdyt ?

        Show
        Emmanuel Lecharny added a comment - What if ONE_LEVEL search done on rootDSE simply return each context entry for all the namingContexts ? Pretty simple to implement , as we know that we are searching from root and that it's a ONE_LEVEL search... wdyt ?
        Hide
        Quanah Gibson-Mount added a comment -

        This is a very real issue, and ignoring it doesn't make it go away.

        I can show you the behavior for OpenLDAP (For ldap.stanford.edu, which has a root of "dc=stanford,dc=edu"

        tribes:~> ldapsearch -x -h ldap -b "" | more

        1. extended LDIF
          #
        2. LDAPv3
        3. base <> with scope subtree
        4. filter: (objectclass=*)
        5. requesting: ALL
          #
        1. stanford.edu
          dn: dc=stanford,dc=edu
          objectClass: dcObject
          objectClass: organization
          o: Stanford University
          dc: stanford
          l: Palo Alto

        (etc)

        More importantly, is how are you going to handle people who have databases rooted at ""? That's what we do at Zimbra, as we support ISP's, and thus multiple domains that could exist across org, com, edu, etc. You should always be able to do a subtree search on "", and it should simply return the databases as they exist (according to ACL rules, etc, of course).

        It is the same as any other subtree search.

        --Quanah

        Show
        Quanah Gibson-Mount added a comment - This is a very real issue, and ignoring it doesn't make it go away. I can show you the behavior for OpenLDAP (For ldap.stanford.edu, which has a root of "dc=stanford,dc=edu" tribes:~> ldapsearch -x -h ldap -b "" | more extended LDIF # LDAPv3 base <> with scope subtree filter: (objectclass=*) requesting: ALL # stanford.edu dn: dc=stanford,dc=edu objectClass: dcObject objectClass: organization o: Stanford University dc: stanford l: Palo Alto (etc) More importantly, is how are you going to handle people who have databases rooted at ""? That's what we do at Zimbra, as we support ISP's, and thus multiple domains that could exist across org, com, edu, etc. You should always be able to do a subtree search on "", and it should simply return the databases as they exist (according to ACL rules, etc, of course). It is the same as any other subtree search. --Quanah
        Hide
        Quanah Gibson-Mount added a comment -

        So, at least with sub, the behavior is fairly clear, it returns whatever it has access to. But with OpenLDAP, using a scobe of "one", using separate databases for the contexts (rather than using ""), I get:

        [zimbra@freelancer ~]$ ldapsearch -x -b "" -s one -h freelancer

        1. extended LDIF
          #
        2. LDAPv3
        3. base <> with scope oneLevel
        4. filter: (objectclass=*)
        5. requesting: ALL
          #
        1. search result
          search: 2
          result: 32 No such object
        1. numResponses: 1

        So if there is no "" database, a one-level search says no such object. I don't know if that's really the correct behavior or not, it's an interesting question.

        Show
        Quanah Gibson-Mount added a comment - So, at least with sub, the behavior is fairly clear, it returns whatever it has access to. But with OpenLDAP, using a scobe of "one", using separate databases for the contexts (rather than using ""), I get: [zimbra@freelancer ~] $ ldapsearch -x -b "" -s one -h freelancer extended LDIF # LDAPv3 base <> with scope oneLevel filter: (objectclass=*) requesting: ALL # search result search: 2 result: 32 No such object numResponses: 1 So if there is no "" database, a one-level search says no such object. I don't know if that's really the correct behavior or not, it's an interesting question.
        Hide
        Quanah Gibson-Mount added a comment -

        So ignore my first bit on Stanford.edu. They have a "defaultsearchbase" value set, which redirects queries to "" to the dc=stanford,dc=edu base. A subtree search when that is not set also returns error 32, no such object.

        Not that this is necessarily the correct behavior.

        Show
        Quanah Gibson-Mount added a comment - So ignore my first bit on Stanford.edu. They have a "defaultsearchbase" value set, which redirects queries to "" to the dc=stanford,dc=edu base. A subtree search when that is not set also returns error 32, no such object. Not that this is necessarily the correct behavior.
        Show
        Kiran Ayyagari added a comment - Fixed here http://svn.apache.org/viewvc?rev=917683&view=rev

          People

          • Assignee:
            Kiran Ayyagari
            Reporter:
            Emmanuel Lecharny
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development