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

Re: non-ascii in slapd.conf and ACL dn matching with non-ascii



On Sat, Aug 17, 2002 at 09:48:43PM +0000, Pierangelo Masarati wrote:
> Kurt D. Zeilenga writes: 
> > At 05:22 AM 2002-08-17, Stig Venaas wrote:
> > Regexing issues aside, slapd.conf(8) values can be UTF-8
> > or escaped per the specification for that value.  For example,
> > a filter in an ACL can be either.  A suffix can be either. 

Right, forget that part, being stupid. Hex-escaping of DNs works if
I use \\ in slapd.conf, problem was rather regexp and pretty vs
normalize, see below.

> >>Next I want to be able to match non-ascii in ACLs. DN matching seems
> >>somewhat problematic. The DN in an ACL is compared to a prettied and
> >>normalized, I'm not so sure we can use the current pretty and normalize
> >>on ACL DNs containing regex, in particular if the ACL DN contains
> >>regexp wildcards. I only want to fix this partly though, by doing
> >>Unicode NFKC on the ACL string, and maybe hex-escaping, see below.
> > 
> > I am, in general, against mucking with regexes.  That is, they
> > should matched literally. 

Yes, maybe you're right, I see several problems myself. Note that case
will not be ignored for non-ascii then, but people can avoid regexp
style if they need that.

> >>Internally we do hex-escaping of non-ascii characters. Why?
> > 
> > We pretty DNs.  The present pretty algorithm should have
> > very minimal escaping, because this is the same form we
> > use on the wire. 

I see that now, it's the normalized form (e.g. e_nname) that
hex-escapes non-ascii, and I'm not sure it's a good idea.

> >>It seems I either have
> >>to hex-escape ACL DN or un-escape the DN I'm comparing against.
> > 
> > The regex needs to match the pretty form of the DN. 
> > 
> > The pretty form should be minimally escaped. 
> > 
> 
> ACL evaluation usually is applied agains entries.  In entries
> we have the nornalized DN (e_nname structure member) but also
> the pretty DN (e_name structure member; they both result from
> applying dnPrettyNormal() to the supplied DN at some stage
> of entry addition).  So whenever we need to do ACL evaluation
> we can use the pretty form as well, since ACL routines are passed
> entries, not strings. 

Okay, the problem is that when doing regex we are not escaping hex,
while we compare with the normalized form, but should compare with
prettied form. Changing the second parameter to regex_matches(),
line 629 in acl.c 1.154, from op->o_ndn.bv_val to op->o_dn.bv_val
seems to do the trick.

> Another point is when parsing the ACL config directives.
> In this case, when reading all but regex matching, the supplied
> string is normalized (dnNormalize2(), I guess).  All we need
> to do is to use dnPretty() instead.  I note that dnPretty()

Right, seems to me things should be okay if we change the above
and change to dnPretty() for regex.

> leaves a few hex escaping (I need to check to be sure, but
> I'm positive ',', '+' and few more are hex escaped). 

Yes, and that's fine of course. It's the additional hex-escaping
done for the normalized form that I'm questioning.

I know my previous mail wasn't very clear, hopefully better now
that I've read your comments and looked more at the source.

Stig