Full_Name: Raphael Ouazana Version: HEAD, RE24, RE23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (164.2.255.244)

Hi,

I repost this here as I think the discussion was lost in a closed ITS (#4860). The two solutions (other operation or previous behavior) would be fine for us, but I have not really time to make a patch for the moment.

Le Sam 10 novembre 2007 16:37, ando@sys-net.it a .crit :

...

Below I represent sets in {element1, element2} notation, to describe

the

...

current behaviour (in HEAD) for slap_set_join on the '+' operation:

• {"One", "Two"} + {"Three", "Four"} ==> {"OneThree", "OneFour",

"TwoThree", "TwoFour"}

• {"One", "Two"} + {""} ==> {"One", "Two"}
• {"One", "Two"} + {NULL} ==> {"One", "Two"}

Although sets lack a specification, I think this behavior is desirable in many cases: adding NULL is equivalent to adding EMPTY ("").

The problem is that {NULL} is equivalent to NULL, ie the empty set.

...

Consider the following set: set="[ldap:///] +

[ldap:///<searchbase>??<scope>?<filter1>] +

...

[??<scope>?<filter2>]"

Assuming [ldap:///<searchbase>??<scope>?<filter1>]

returns a DN, this

...

works. However, if

[ldap:///<searchbase>??<scope>?<filter1>] returns no

...

entries, this value is NULL. Therefore, the rest of the set becomes: "[ldap:///] + {NULL} + [??<scope>?<filter2>]" ...which is handed to the '+' operation in slap_set_join, to become: [ldap:///??<scope>?<filter2>] ...which obviously isn't valid.

Well, it is valid: it's an URI with an EMPTY DN.

In terms of LDAP, yes, but it can cause security issues here, as the EMPTY DN is at a higher level that any one which would have been returned by a normal result.

...

The attached patch changes the last case of the current behaviour for slap_set_join on the '+' operation. This was already the behaviour before version 1.24.2.6 Thu Sep 13 20:43:29 2007 UTC:

• {"One", "Two"} + {NULL} ==> {NULL}

This is different from the above behavior, although it makes sense on its own. Probably we need two different addition operators: one inclusive (NULL is equivalent to "") and one exclusive (NULL nullifies the concatenation).

Comments?

No problem in having the two operators. I just think the normal behavior is to return NULL, has in term of sets the cartesian product A x NULL returns NULL, not A.

Regards, Raphael Ouazana.