RE: [EXTERNAL] Re: Lazy quantifiers in regex ACLs??

[Jon C Kidder <jckidder@aep.com>]

Perfect! Thank you Philip. That was exactly what I needed to keep moving forward!

-Jon C. Kidder

-----Original Message-----
From: Philip Guenther <pguenther@proofpoint.com> 
Sent: Wednesday, October 2, 2019 12:55 PM
To: Jon C Kidder <jckidder@aep.com>
Cc: openldap-technical@openldap.org
Subject: [EXTERNAL] Re: Lazy quantifiers in regex ACLs??

This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments. If suspicious please click the 'Report to Incidents' button in Outlook or forward to incidents@aep.com from a mobile device.

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