Re: ACI developmental status

[Quanah Gibson-Mount <quanah@stanford.edu>]

--On Monday, May 09, 2005 10:37 PM +0200 Hallvard B Furuseth 
<h.b.furuseth@usit.uio.no> wrote:

> Quanah Gibson-Mount writes:
> > 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.
>
> 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.

We do this quite extensively because of US Federal Law, and Stanford 
internal practices.  If it is designed correctly, there is no need to go 
back and revisit the ACL's.  I also find the general belief that having 
lots of ACL's impacts performance holds little water in modern versions of 
OpenLDAP.  My ACL file is 614 lines long, and contains very ugly regex's 
and set statements, and the systems continue to be blazingly fast.  Having 
the rules in place have actually been extremely helpful when having to 
limit data exposed to applications based on private, stanford-only, and 
public visibilities (we have 3. ;) ).

Using your example of the mail attribute, ours looks like:

access to dn.children="cn=people,dc=stanford,dc=edu" 
filter=(suvisibemail=stanford) attrs=mail
   by dn.children="cn=accounts,dc=stanford,dc=edu" sasl_ssf=56 read
   by group.base="cn=stanfordauth,cn=Applications,dc=stanford,dc=edu" 
sasl_ssf=56 read
   by * break

access to dn.children="cn=people,dc=stanford,dc=edu" 
filter=(suvisibemail=world) attrs=mail
   by dn.children="cn=accounts,dc=stanford,dc=edu" sasl_ssf=56 read
   by group.base="cn=stanfordauth,cn=Applications,dc=stanford,dc=edu" 
sasl_ssf=56 read
   by anonymous read
   by * break


<http://www.stanford.edu/services/directory/trees/people.html> contains a 
list of the myriad visibility attributes we have, and what they control.

All user data is of course, filtered through an application, and no user 
ever is allowed to modify the directory servers directly (with the 
exception of myself and a few other admins. :P ).

> Do you have a better suggestion for such ACLs?

No, I think it is an excellent scheme, actually.


> For that matter, what if you want to allow users write access to the
> access controls for their own entries?

Its true it doesn't address this, but that's one heck of a vulnerability 
that I wouldn't want on my systems. ;)

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html