I'm tuning my ACLs, and noting that we have several pieces of software that require the presence of a specific objectclass. Up to this point, they have write access to the objectclass attribute and can add the specific auxiliary class if needed and then modify the attributes that come with it.
I'd like to pare down their access. It'd be nice to be able to allow them to add and remove the specific objectclass that they work with (in this case, posixAccount) but not touch the other objectclasses they have no business modifying (person, etc).
Can an ACL work at this fine-grained a level? I'm going over the 2.4 docs and the FAQ-o-matic, but not coming across anything. (Though I'm certainly building a very nice "Ooo, I should do <x> that way..." list...)
Brandon Hume wrote:
I'm tuning my ACLs, and noting that we have several pieces of software that require the presence of a specific objectclass. Up to this point, they have write access to the objectclass attribute and can add the specific auxiliary class if needed and then modify the attributes that come with it.
I'd like to pare down their access. It'd be nice to be able to allow them to add and remove the specific objectclass that they work with (in this case, posixAccount) but not touch the other objectclasses they have no business modifying (person, etc).
Can an ACL work at this fine-grained a level? I'm going over the 2.4 docs and the FAQ-o-matic, but not coming across anything. (Though I'm certainly building a very nice "Ooo, I should do<x> that way..." list...)
Yes. Read slapd.access(5).
access to attrs=objectclass value=posixAccount by <someone> write
openldap-software@openldap.org
-
Brandon Hume -
Howard Chu