[Date Prev][Date Next]
Re: Problems with slapcat/slapadd in upgrade from 2.2.23 to 2.3.11
On 21 Oct 2005, at 01:02, Howard Chu wrote:
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:
I read aci.c in 2.3.11 and I am more comfortable with the syntax,
Is there a reference on ACI syntax? What is wrong with this
specificThere is no formal specification (yet); values that used to be
still legal, and few extensions have been added in HEAD. Of
ACIs need to be explicitly enabled by using --enable-aci at
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
error while writing new rules, rather than having them silently
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.
We are brave and bold and needing documentation is all. But I can
read C code and aci.c was very helpful. I was just freaked out
because it was holding up the upgrading of 36-some-odd servers.