On Sat, 26 May 2012, Nick Milas wrote:
On 25/5/2012 6:59 ??, Nick Milas wrote:
You mean that if we use a <what> statement without an "attrs=" clause, then it affects children and entry pseudo-attributes as well? And what if there is a filter specified too (still without an "attrs=" clause)?
From some research I did (e.g.: http://www.openldap.org/faq/data/cache/1140.html), I don't see cases of implicit change (meant as described above) of entry and children pseudo-attributes.
You didn't see the last example on that page? ---- access to dn.onelevel="dc=example,dc=com" by dnattr=creatorsName write by * read ----
No attrs clause, and yet for the behavior described there to work it must be giving access to the 'entry' pseudo-attr.
In case we would like an ACL statement to include all attributes *plus* the pseudo-attributes, then we should explicitly specify, for example:
access to dn.subtree="ou=people,dc=example,dc=com" attrs="@extensibleObject,children,entry" by dn.exact="uid=admin,ou=people,dc=example,dc=com" write ...
@extensibleObject covers *EVERYTHING*, including the pseudo-attrs entry and children.
If anyone has more details on this, I would appreciate your feecback.
Let's do something *crazy*: let's *actually try it*!
I added the following two acls to an existing server ----- # Just needed so I can add dc=testing... access to dn.exact="" attrs=children by dn.exact="mailRoutingAddress=foo@foo.com,ou=People,dc=foo,dc=com" write
access to dn.sub="dc=testing" by dn.exact="mailRoutingAddress=foo@foo.com,ou=People,dc=foo,dc=com" write -----
This server had no dc=testing tree at this point. With those ACLs present, I was then able to bind as the indicated user and create a dc=testing entry and an entry below it:
$ ldapadd -D mailRoutingAddress=foo@foo.com,ou=People,dc=foo,dc=com -w foobar dn: dc=testing changetype: add objectclass: domain dc: testing
adding new entry "dc=testing"
dn: ou=foo,dc=testing objectClass: organizationalUnit ou: foo
adding new entry "ou=foo,dc=testing"
$
So, no attrs clause on the second ACL but I was able to create entries covered by it.
I then replaced those two ACLs with this single one: ----- access to dn.sub="dc=testing" attrs="objectclass,ou,entry" by dn.exact="mailRoutingAddress=foo@foo.com,ou=People,dc=foo,dc=com" write -----
I.e., the ACL no longer gives write access to the 'children' pseudo-attribute.
Adding an entry then fails:
$ ldapadd -D mailRoutingAddress=foo@foo.com,ou=People,dc=foo,dc=com -w foobar dn: ou=baz,dc=testing objectClass: organizationalUnit ou: baz
adding new entry "ou=baz,dc=testing" ldap_add: Insufficient access (50) additional info: no write access to parent
$
I then updated that ACL to include children: ----- access to dn.sub="dc=testing" attrs="objectclass,ou,entry,children" by dn.exact="mailRoutingAddress=foo@foo.com,ou=People,dc=foo,dc=com" write -----
...and now the same add succeeds:
$ ldapadd -D mailRoutingAddress=foo@foo.com,ou=People,dc=foo,dc=com -w foobar dn: ou=baz,dc=testing objectClass: organizationalUnit ou: baz
adding new entry "ou=baz,dc=testing"
$
Those two tests together show that the server is indeed checking for the 'children' attr, so it's not that it just wasn't looking.
Finally, let's try using attrs="@extensibleObject" (I only mention it because that's what the *documention* says is the default.) ----- access to dn.sub="dc=testing" attrs="@extensibleObject" by dn.exact="mailRoutingAddress=foo@foo.com,ou=People,dc=foo,dc=com" write -----
$ ldapadd -D mailRoutingAddress=foo@foo.com,ou=People,dc=foo,dc=com -w foobar dn: ou=quux,dc=testing objectClass: organizationalUnit ou: quux
adding new entry "ou=quux,dc=testing"
$
So @extensibleObject clearly must cover 'children'.
I suggest you set up a similar test environment and play around with some ACLs on a real system. Less theory and more practice will lead to faster results. For example, you could set up an ACL with a filter clause and answer your own question about whether that affects the attrs matched.
Philip