Kean Johnston wrote:

...

This patch was rejected. The functionality it offered was already provided by the slapd ACL engine.

Could I ask you to reconsider your position on using ACL's? Using ACL's for this kind of thing is a little bit like asking the security guard that makes your entry badge also be in charge of all of your HR data and documents. I understand the ACL engine may be quick but it completely defeats the purpose of having a centralised directory.

No, doing anything else defeats that purpose.

What if I want directory administrators to be able to edit host permissions but I don't want them to have root so they can edit slapd.conf or change the SLAPD configuration?

So let them edit the host permissions. Delegate the privileges to groups, and give them write access to their respective groups.

what if I cant even use the modern configuration because overlays I want to use don't support it and I am forced to use slapd.conf?

Irrelevant. Using slapd.conf doesn't preclude delegation of privileges or dynamic updates to privilege memberships.

It also moves away from the model of having data about the host in one dn: cn=host,dc=example,dc=com entry to now having pretty vital information about the host moved completely out of the directory itself and into the directory server's configuration. That surely can't be a good thing.

On the contrary - for security management, it's the BEST thing. Keeping your authorization rules scattered across the data space not only makes it harder to administer, it also makes it easier to subvert. Keeping it all isolated in a single administrative space negates both of those problems.

The key to scalable security is centralized control with distributed access, not distributed control. The more widely you distribute the actual points of control, the more likely you are to make a mistake and open a hole between the points.

What if I want to move from OpenLDAP to some other server?

Then you probably should be using nss-pam-ldapd, and not nssov.