On 27/5/2012 6:33 πμ, Philip Guenther wrote:
@extensibleObject covers*EVERYTHING*, including the pseudo-attrs entry and children.
Then, the first example at: http://www.openldap.org/faq/data/cache/1140.html is a bit deceptive, or it just aims in emphasizing the entry pseudo-attr, by specifying it explicitly (along with @extensibleObject), when there was no need to.
You didn't see the last example on that page? ... No attrs clause, and yet for the behavior described there to work it must be giving access to the 'entry' pseudo-attr.
True, but one could think that the example here empasizes (because this is what it discusses) the assignment of write privileges and is incomplete with regard to the assignment of read privileges.
Let's do something*crazy*: let's*actually try it*!
Ha, ha! Thanks Philip. You were great! I was just too lazy! (Too busy as well, or hoping someone would know and clarify things so we would avoid testing thoroughly.)
So there is a risk of "implicit" inadvertent changes!
To summarize your findings:
attrs="@extensibleObject" EQ attrs="@extensibleObject,entry,children" EQ NO attrs= clause
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.
OK, I'll do it.
Nick