Re: 2.3.1alpha and ACL set matching

[Pierangelo Masarati <ando@sys-net.it>]

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 ) {
>                        break;
>                    }
>  
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.

p.


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