Re: 2.3.1alpha and ACL set matching

[David Hawes <dhawes@vt.edu>]

On Thursday 17 March 2005 16:33 pm, Pierangelo Masarati wrote:
> 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.

I certainly agree that the patch is a workaround--I didn't really consider all 
the normalization issues, though I was pretty sure they existed.

I really just wanted to test and make sure sets at least work in 2.3.  They 
certainly do, but, as you say, some extra care must be taken with the rules.  
It seems like the ideal would be to match set members with the attribute's 
MatchingRule using value_match() or something similar (where appropriate), 
but I'm sure this opens up numerous other issues.  

Out of curiosity, where in the FAQ are these changes noted?  Also, the 
preferredLanguage example will not work with 2.3 due to the case insensitive 
match.  

Thanks for your reply.  I use sets extensively in my directories and certainly 
want to see them no longer be labeled "experimental".  I'm definitely 
watching the other thread...

dave