> 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:[EMAIL PROTECTED] SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
