[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: non-ascii in slapd.conf and ACL dn matching with non-ascii
At 04:34 AM 2002-08-18, Stig Venaas wrote:
>> >>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.
The DN normalization value (e_nname) *should be*
a) normalize each value per its syntax (e.g., full
string prep including case mapping, insignificant
space removal)
b) minimally escaped
and regex should match against it, not e_name (despite what
I said before, see below). This way matching is done against
normalized values (in the AVAs).
>> >>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.
This is problematic. The pretty form could have a value
like <CN=foo bar> (note the two spaces). We should match
against the normalized version <CN=foo bar>.
>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.
I think this needs to be reversed. Instead, we need to fix
the ndn escaping.
Kurt