Re: Lazy quantifiers in regex ACLs??

[Philip Guenther <pguenther@proofpoint.com>]

On Wed, 2 Oct 2019, Jon C Kidder wrote:
> Does the regex engine in OpenLDAP not support lazy quantifiers?  Why 
> does the ACL processing in this log show only one capture group as if 
> the lazy quantifier in the first capture group isn't recognized?  Every 
> tester I plug this regex into produces 2 capture groups which is what I 
> need.  I need to carve off the leading OU as one capture group and 
> capture the remaining chain of OUs as the second group then re-use both 
> in my ACLs.  Any suggestions for creating a regex that would produce the 
> desired capture groups for use in my ACLs?
> 
> 5d94aa15 => dnpat: [18] (ou=.+?,)?(ou=.+,)?ou=Delegated,ou=ApplicationData,dc=global,dc=aep,dc=com$ nsub: 2

Lazy quantifiers, (aka stingy or minimal matches) are a feature of 
perl-compatible regexps and are not part of the regexp functions called by 
openldap for ACL processing.  Per the slapd.access(5) manpage:
       If  the  <dnstyle>  qualifier  is  regex,  then  <dnpattern> is a POSIX
       (''extended'') regular expression  pattern,  as  detailed  in  regex(7)
       and/or re_format(7), matching a normalized string representation of the
       entry's DN.  The regex form of  the  pattern  does  not  (yet)  support
       UTF-8.

POSIX extended regexps do not include minimal matching.


That said, minimal matches can often be more precisely written by putting 
a less general regexp, one that matches a more specific set of inputs, to 
the left of them.  In this case, you probably want the ".+?" in 
"(ou=.+?,)?" to never match a comma, as that would mean multiple DN 
components were being included in that submatch.  So, I would suggest 
trying
     (ou=[^,]+,)?(ou=.+,)?ou=Delegated,ou=ApplicationData,dc=global,dc=aep,dc=com$
	

This will have the same effect when the leading DN components are all 'ou' 
types.  It'll behave differently if you were to have a DN that had some 
other type of component in there.  For example, if the DN
	ou=foo,l=home,ou=bar,ou=Delegated,ou=ApplicationData,dc=global,dc=aep,dc=com

was to be tested, and minimal match was actually supported, then your 
original regexp would have *matched* with
	$1 = ou=foo,l=home,
	$2 = ou=bar,

while the regexp I suggest about will instead match
	$1 =
	$2 = ou=foo,l=home,ou=bar,

If you wouldn't want such a (weird) case to match at all then you would 
want to tighten the second group as well, ala
     (ou=[^,]+,)?(ou=[^,]+,)?ou=Delegated,ou=ApplicationData,dc=global,dc=aep,dc=com$

or maybe...
     (ou=[^,]+,)?((ou=[^,]+,)+)?ou=Delegated,ou=ApplicationData,dc=global,dc=aep,dc=com$

...but it depends on what you want to happen when there are more than two 
components before the ou=Delegated component.


Philip Guenther