Re: Another 2.2.23 oddity

["Pierangelo Masarati" <ando@sys-net.it>]

> Expecting the answer 'upgrade' again, but thought I'd mention it:
>
> We have a slightly odd schema, where basically
> cn=<USER>,ou=users,dn=foo has children,
> cn=<THING>,cn=<USER>,ou=users,dn=foo
>
> and a set of attr permissions, of which the key one is that
> cn=<USER>,ou=users,dn=foo can read/write to any children of it.
>
> THIS works when bound as cn=a:
>
> Oct  5 16:59:20 dev slapd[12626]: conn=7 op=17 ADD
> dn="cn=fullname,cn=a,ou=users,dc=foo"
> Oct  5 16:59:20 dev slapd[12626]: conn=7 op=17 RESULT tag=105 err=0
> text=
>
> THIS fails when bound as cn=a(b)
>
> Oct  5 17:09:08 dev slapd[12626]: conn=9 op=6 ADD dn="cn=fulltext,cn=a
> (b),ou=users,dc=foo"
> Oct  5 17:09:08 dev slapd[12626]: conn=9 op=6 RESULT tag=105 err=50
> text=no write access to entry
>
> Reasonably exhaustive testing seems to suggest it's the brackets. Any
> thoughts?

I guess you're using some ACL that performs "regex" patch on a pattern
computed using submatches; if this is the case, the second regex matching
interprets the brackets in the value as part of the pattern.  submatches
may need regex-escaping before being used in buildning patterns for
further regex matching, unless building submatch-dependent patterns is
intended.

A sample of your access rules would be of help.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497