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

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



[resent due to (*hopefully* fixed) list problems]
At 05:22 AM 2002-08-17, Stig Venaas wrote:
>There seems to be no way to specify non-ascii in slapd.conf, this is
>for instance needed when one wants to supply non-ascii characters in
>ACLs or use non-ascii in database suffixes. I want to fix this. I
>suggest using hex-escaping like say "\3e". Sounds okay?

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.

slapd(8) should pretty/normalize the value as need, whether
that value is a DN, a filter, or something else.

>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.

>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.

Unlike the algorithm used by by numerous client tools,
which pretty much do escape all non-ASCII.

>I would think it was more efficient to not do that, and only do it when we
>print strings to logs and other debug output.

Presently, we're not escaping logs/debugging.

>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.