Hallvard B Furuseth wrote:
Quanah Gibson-Mount writes:First of all, nobody is talking about removing ACI support from OpenLDAP, so let's let that question drop.
With OpenLDAP 2.3, it will be possible to replace all your *.conf
files with the new back-config DB. This will allow ACL's to be
modified on the fly, and remove the need for ACI's at all. ACL's are
somewhat more powerful than ACI's, so I myself see little reason for
them to even remain once OL 2.3 is released.
From a usability standpoint I agree with you. I worked on file servers before coming to OpenLDAP and that has always colored my view of how the directory should work. (I.e., why isn't it just like a filesystem? E.g. back-bdb/ldbm - why no support for tree renames (back-hdb), what about mount points (back-ldap, backglue), what about hard links...) But this suggestion of yours would be an enterprise security manager's nightmare. The potential for abuse is unbounded. I think this vulnerability could be lessened somewhat by borrowing another filesystem notion - per-user storage quotas. Then at least, if a user carelessly leaves themselves wide open, you can limit the damage that can be done.Our site needed ACIs when employees could choose to make their entries or selected attributes in them visible to only some people.
Well, it would be possible to introduce a 'hide' attribute instead and insert a bunch of statements like this in slapd.conf: access to filter=(hide=mail:foo) attrs=mail by <foo> none by * none break but this is not exactly elegant, it scales poorly and it's also easy to make a typo in the ACLs.
Do you have a better suggestion for such ACLs?
For that matter, what if you want to allow users write access to the access controls for their own entries?
-- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support