Thank you all for the replies! I actually have been using the dn.subtree syntax on each ACL, which works great. Right now, I am the only admin of this system, so this is simple. However, as a few more admins get involved, with their own suffixes/databases, I'd like to give them their own db-xyz.acl file, included in slapd.conf for their database. I trust them to not do anything malicious on purpose -- but I also want to safeguard against them simply reading something from google, and implementing a "access to * by * write", for example, and having that affect RootDSE and Schema. For now, I may just give them their own instances of OpenLDAP, running on a different URI. Thanks for the input, -Matt On Tue, 2004-11-02 at 11:49, Pierangelo Masarati wrote: > I think this happens mostly for historical reasons, and cannot be changed > to avoid breaking existing configurations, but I partly agree with your > considerations. There is a clean workaround for this: > > 1) write global ACLs that refer to rootDSE/cn=Subschema/cn=Monitor and so > 2) clearly define the scope of per-database ACLs. In HEAD code, all the > times out of scope ACLs are used, a warning at startup appears. For > instance (stupid example): > > This is fine > <slapd.conf> > # global > access to dn.subtree="" > by * read > > database <any> > suffix "dc=example,dc=com" > access to dn.subtree="dc=example,dc=com" attrs=userPassword > by self write > by * auth > access to dn.subtree="dc=example,dc=com" > by users read > </slapd.conf> > > This is the same, but causes a warning > <slapd.conf> > database <any> > suffix "dc=example,dc=com" > access to attrs=userPassword > by self write > by * auth > access to dn.subtree="dc=example,dc=com" > by users read > access to dn.subtree="" > by * read > </slapd.conf> > Note that the difference is that the attrs=userPassword rule in the latter > case has global scope (dn.subtree=""), but only affects the first database > and the rootDSE and so, unless the following databases do not catch > accesses to userPassword, which is unlikely. > > The warning forces administrators to writing well-defined ACLs. Of > course, you need to write twice what you could have written just once, > and, moreover, each of the access directives of database 1 are tried > before getting to the global ones. Of course, the use of the base/scope > in the directives of database 1 makes them be skipped directly, without > even trying, because the suffix is longer than the (empty) base. > > > All- > > Section 5.4 of the online Handbook states, regarding ACLs: > > "As this is the first database, the controls also apply to entries not > > held in any database (such as the Root DSE)." > > > > It seems "funky" to me to have ACLs from one database definition apply > > to data that does not exist in that database. In the interest of > > planning ahead, I'd like to ask: are there any plans to implement a > > change in this behavior? I see one of two approaches: > > *Implement config sections to explicitly define Schema and RootDSE > > params. > > *Anything not explicitly defined in a database definitions falls under > > the Global ACLs. > > > > I am just curious if there will be a change to this, as I find it a > > little "awkward" trying to keep each set of database configs in it's own > > modular location, and I don't necessarily have the same database listed > > first in all replicas, so the ACLs can't necessarily be copied verbatim. > > > > Is there already a work-around that I am unaware of? Is this a > > problem for anyone else, or is it just me? > > > > Thanks all, > > -Matt > > > > -- > > Matthew J. Smith <matt.smith@uconn.edu> > > University of Connecticut ITS > > PGP Key: http://web.uconn.edu/dotmatt/matt.asc > > -- Matthew J. Smith <matt.smith@uconn.edu> University of Connecticut ITS PGP Key: http://web.uconn.edu/dotmatt/matt.asc
Attachment:
signature.asc
Description: This is a digitally signed message part