Questions regarding certain ACL constructs - openldap-technical

9 Jul 2020


      Hi,
Just wanted to ask/clarify about few things related to ACLs:
1) @extensibleObject
In one of the faq entries, namely:
https://www.openldap.org/faq/data/cache/1140.html
there is a construct that looks superfluous:
access to dn.onelevel="cn=bar,ou=Stuff,dc=example,dc=com" 
attrs=entry,@extensibleObject
Doesn't @extensibleObject include everything - entry, children and 
regular attributes - by default ?
That's what I'd imply from the official documentation that states that 
not explicitly specifying attrs= is equivalent to attrs=@extensibleObject
If so, then the above is equivalent to just:
access to dn.onelevel="cn=bar,ou=Stuff,dc=example,dc=com"
2) entry pseudo-attribute vs writing to regular attributes
This is one thing that somewhat surprises me - as the read/search access 
explicitly requires relevant access to entry pseudo-attribute (as per 
OPERATION REQUIREMENTS from slapd.access manpage).
The write access on the other hand doesn't mention any requirements 
besides add/delete/write to the attribute itself. This actually holds 
true right ?
3) attr based access
In one of the examples (8.4.5. Granting access to a subset of 
attributes), question regarding:
# immediate children: only self can add/delete entries under this entry
access to attrs=children
   by self write
# entry itself: self may write, all may read
access to attrs=entry
   by self write
   by * read
They still do require other ACLs, as "selfs" in both cases are 
different, right ? E.g. if self matches parent, it won't match children 
being created and vice-versa (and as per the manual page - 'add' is 
required both for parent's 'children' as well as new entry's 'entry'). 
ITOW if we bind as the entity wanting to create new entry underneath, 
the above is not enough - and we need something more elaborate like in 
e.g. address book example.
4) access rights required for deeper searches
suppose we have structure like:
ou=A, dc=example, dc=com
ou=B, ou=A, dc=example, dc=com
uid=msl, ou=B, ou=A, dc=example, dc=com
If we do search for uid using 'ou=A, dc=example, dc=com' as a search 
base (with subtree scope), what (if any) access rights do we need on 
'ou=B, ou=A, dc=example, dc=com' ?
5) sets
Is this feature assumed safe to use ? As - it's still formally 
undocumented (man pages), but there are examples on the website and 
syntax explanation in the faq.