[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: 2.3.1alpha and ACL set matching

David Hawes wrote:

In 2.3.1alpha (and HEAD), set matching is no longer case insensitive like it is in 2.2.x versions. I am not sure if this is intended or not--the only documentation I am aware of claims that "operators are case sensitive" ( http://www.openldap.org/faq/index.cgi?_highlightWords=sets&file=1133).

If case sensitive matching is intended, set matching can be thrown off by attribute matching rules defined in the schema. For instance, if I have an attribute called 'accountState' that has caseIgnoreMatch equality matching and use a similar ACL (excerpt):

	by set="user/accountState & [INACTIVE]" none

, 2.3 will never be able to match it as backend_attribute always returns the value in lower case. Of course, the matching will work if INACTIVE is lower case in the ACL. If this behavior is by design, I think it should be noted in the documentation so users are at least aware of it.

If case sensitive matching is not intended, a patch like the following should restore 2.3.1alpha to do case insensitive matching (please note that this patch is only for the '&' operator):

--- openldap-2.3.1alpha/servers/slapd/sets.c Thu Jan 20 13:03:56 2005
+++ openldap-2.3.1alpha-patch/servers/slapd/sets.c Thu Mar 17 12:25:16 2005
@@ -201,7 +201,7 @@
last = slap_set_size( set ) - 1;
for ( i = 0; !BER_BVISNULL( &set[ i ] ); i++ ) {
for ( j = 0; !BER_BVISNULL( &rset[ j ] ); j++ ) {
- if ( bvmatch( &set[ i ], &rset[ j ] ) ) {
+ if ((ber_bvstrcasecmp(&set[ i ], &rset[ j ])) == 0 ) {

I'm happy you raised the point, because that change was by design, but I don't consider it frozen yet. The point is that we are currently using the normalized form of the values when building the set, because backend_attribute is returning that and because the opposite would make little sense. I understand this may imply some extra care when writing rules, but I'd consider the patch you suggest a workaround rather than a fix, because in normalization there may be more than just ignoring case; there's also ignoring extra spaces for directory strings, there's ignoring some chars in telephone numbers, and so; I'd use appropriate normalization routines on static strings, if substring expansion were not an option, and if performances were not an issue. I agree that this change should be noted somewhere; in fact, I noted it in the FAQ, because that's the only documentation currently available for sets. As soon as they are no longer experimental (see the discussion in parallel on this list), more "official" docs might be produced; at least, sets should get documented in slapd.access(5). Further comments are welcome.


SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497