Re: ACLs applying to RootDSE

["Pierangelo Masarati" <ando@sys-net.it>]

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
>


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497