We create the aci with the --test flag to test its validity but it doesn't
do the same level of tests that actually adding an aci to LDAP does. Catch
any syntax errors that get thrown and clean up as best we can.
ticket 621
The change_password permission was too broad, limit it to users.
The DNS access controls rolled everything into a single ACI. I broke
it out into separate ACIs for add, delete and add. I also added a new
dns type for the permission plugin.
ticket 628
permissions are a real group pointed to by an aci, managed by the same
plugin. Any given update can update one or both or neither. Do a better
job at determining what it is that needs to be updated and handle the
case where only the ACI is updated so that EmptyModList is not thrown.
ticket 603
This is just a thin wrapper around the aci plugin, controlling what
types of ACIs can be added.
Right now only ACIs in the basedn can be managed with this plugin.
ticket 531
The new model is based on permssions, privileges and roles.
Most importantly it corrects the reverse membership that caused problems
in the previous implementation. You add permission to privileges and
privileges to roles, not the other way around (even though it works that
way behind the scenes).
A permission object is a combination of a simple group and an aci.
The linkage between the aci and the permission is the description of
the permission. This shows as the name/description of the aci.
ldap:///self and groups granting groups (v1-style) are not supported by
this model (it will be provided separately).
This makes the aci plugin internal only.
ticket 445
Rob Crittenden