[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problems with slapcat/slapadd in upgrade from 2.2.23 to 2.3.11

Pierangelo Masarati wrote: 
On  20 Oct 2005, at 14:24, Pierangelo Masarati wrote:

On Thu, 2005-10-20 at 13:29 -0700, Charles Stephens wrote:

Is there a reference on ACI syntax?  What is wrong with this specific
entry?

There is no formal specification (yet); values that used to be
legal are
still legal, and few extensions have been added in HEAD. Of course,
ACIs need to be explicitly enabled by using --enable-aci at configure.
I read aci.c in 2.3.11 and I am more comfortable with the syntax, but
it is still scary that there isn't anything even roughly documented.

Look, the syntax is exactly as it was before; only, now you catch blatant
error while writing new rules, rather than having them silently discarded
at ACL evaluation.  What's more scary?

ACI has been marked "experimental" for years. Frankly, that *should* be scary enough all by itself to steer people away from it. As experiments go, if it was successful it should have graduated out of experimental status by now. The fact that it hasn't should be strong hint...

Security management is hard enough as it is. If you can't define a coherent policy, then you clearly have no chance of enforcing it, or even validating whether the real system behavior conforms to the policy. When you allow access control rules to be attached to the directory entries they govern, that essentially means pieces of your security rules are created and deleted on the fly as a *side effect* of creating and deleting the data. Clearly in such a situation you have *no* coherent security policy, which in my book is equivalent to having no security. *That's* scary.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/