[Date Prev][Date Next]
Re: Case (in)sensitivity in 'by set' ACL?
> We have a number of ACLs, in production on OpenLDAP 2.2.26, which are of
> the form:
> by set="user/eduPersonAffiliation* & [Faculty]" read
> where the case of the attribute value in a given entry matches the ACL
> as shown, and the eduPersonAffiliation attribute is
> In testing these ACLs on 2.3.21, I found that the ACLs never match,
> because the bvals returned from the entry () are returned as downcased,
> but the comparison apparently is done case sensitively.
/case sensitively/using octetStringMatch/
> I assume this behavior could be correct, although it seems illogical,
> and has apparently changed.
many things changed in sets since that; much like in the rest of slapd.
> In any case, is this the defined or
> intended behavior?
The intention is always to change for the better; typically, users that
find that things that used to work earlier don't work any more were
relying on incorrect assumptions.
Sets are weakly typed (actually, they're untyped) because they are
intended to mix up stuff in string form, much like regular expressions
(which are case insensitive by default). Since there is no formal
specification of sets, their implementation uses the normalized value when
expanding stuff, while it uses case-sensitive comparison (actually,
octetStringMatch). As a consequence, literals should be provided in
normalized form, whatever it is. Simple case-insensitive comparison would
not suffice, as the normalized form of many matching rules implies much
more than case insensitivity (think of telephoneNumberMatch, for example).
There has been discussion, in the past, about the opportunity to have a
more formal specification of sets, and to extend their syntax to allow to
specify what matching rules should be used to compare values (much like in
extensible match filters). Feel free to suggest improvements; however, I
believe that sets are so "specialized" that they require some deep
knowledge of the internals of slapd (consider that they're essentially
undocumented); this knowledge should imply the capability to provide
normalized strings as literals.
Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team
Via Dossi, 8 - 27100 Pavia - ITALIA