[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#3819) Strange slapd.conf diagnostic after authz-regexp



h.b.furuseth@usit.uio.no wrote:
>  Howard Chu writes:

> > Yes. This was discussed recently
> > http://www.openldap.org/lists/openldap-devel/200504/msg00045.html
> > but I don't think any course of action was decided.

>  Well, I miss some way to set up "non-database" ACLs separately from
>  global ACLs.

>  My suggestion (without looking at the code:-) would be to either
>  implement a 'database dsa-info' to hold this info, or restore the
>  'first database' hack.  With the latter, one can set up a dummy
>  database as the first database if needed.  I knew back-null would be
>  good for something, sooner or later:-)  Can't use it for the root
>  DSE's rootdn, though.

> >> Also, rootdn/rootpw was also applied from the first database, but
> >> those are now taken from frontendDB and I can't get
> >> rootdn/rootpw from frontendDB to work.

>  As for the required non-global and thus different rootdns (when
>  rootpw is used), I don't know what's good about that - it's just been
>  a minor pain in the neck with our setup.  Until I finally learned
>  about ldapi:// -QYEXTERNAL, so no we have the same rootdn for every
>  database.

So it sounds like you're in favor of a single global rootdn. It might 
make sense to use the frontendDB for this.

I suppose your "database dsa-info" idea already exists in "database 
config". Certainly its contents are dsa-specific info, and the config 
database is now always the first database. So, even though back-config 
performs no ACL checks of its own, you can always do
    database config
    access to ...

to setup your non-database ACLs.

We need to tweak the olcGlobal definition to allow this info to be 
propagated in back-config though. Currently there's an ugly game to get 
rootpw in there. We may need to do the same thing to allow setting a 
rootdn here. Then in this case, it would make more sense to me to use 
back-config's rootdn as the server global rootdn. (Because that gets 
exposed in the cn=config root entry.) I've unfortunately confused the 
concepts of "global to the server settings" (cn=config) with "global to 
the database contexts" (frontendDB) in the code; this needs to be 
separated out again.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support