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
