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

Re: ACL regex and Unicode (was: acl again)

At 05:26 AM 2001-11-10, Pierangelo Masarati wrote:
>[moved from -devel]
>> > without extra intervening spaces.
>> Maybe we should try to normalize that in the code when parsing the rule?
>> I should look into Unicode and ACLs, we need to decide what to try to
>> normalize though. Normalization and regexps are a bit awkward, even more
>> so when taking Unicode into account.
>I read in some posting from Kurt that there are plans to implement
>Unicode regex; I guess you're working on that.  I agree we'd try to
>normalize ACLs as well.

I note that one has to be extremely careful mucking with regular
expressions.  What we need to do is to better normalize the DN being
matched against such that we might be better able to normalize
the asserted regex.  For example, by requiring specials in values
to be hex escaped instead of simple backslash escaped means that
the only comma in the stored value is the RDN separator and that
MAY mean one can safely remove all spaces after commas in the asserted
regex.  We need to be conservative here, that is, we should only
do those regex rewrites which we can prove are safe.

>Recently I've been working on DN parsing
>and I gave a look at ACL as well to see if there's anything that needs
>be done in terms on normalization and so.  IMHO those ACL regex that
>apply to DNs should be split in DN components and operate on the LDAPDN

I don't know how one could actually do that.  I think ACL DN regexes
need to act upon a string representation of the whole DN.

>So we might start from the DN structures created by 
>ldap_str2dn and introduce a new function that parses a DN according
>to regex rules.  I'm unaware of the implications of regex matching,
>so I'll have a look at the current code to see how it fits in my ideas.
>This might come after I work on dn validate/normalize starting from 
>the LDAPDN structure.