[Date Prev][Date Next]
Re: non-ascii in slapd.conf and ACL dn matching with non-ascii
Kurt D. Zeilenga writes:
[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.
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.
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()
leaves a few hex escaping (I need to check to be sure, but
I'm positive ',', '+' and few more are hex escaped).
Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano | mailto:email@example.com
via La Masa 34, 20156 Milano, Italy | http://www.aero.polimi.it/~masarati