Re: (ITS#4962) inconsistent Bind(rootdn) behavior

[ghenry@suretecsystems.com]

ando@sys-net.it wrote:
> h.b.furuseth@usit.uio.no wrote:
> 
>> Backends are quite inconsistent about how Bind treats rootdn/rootpw.
>> After a quick browse of the HEAD code, it looks like this - I'll
>> investigate closer if needed:
>>
>> rootpw supported:
>>     Yes: config, bdb, meta, monitor, ldif, HEAD:null, sql, overlay retcode.
>>     No:  dnssrv, ldap?, RE23:null, perl, relay, shell.
> 
> back-ldap doesn't care about rootdn/rootpw; back-meta does mostly for
> historical reasons (could be removed with some work).
> 
>>     (Bind not supported: passwd).
>>
>> Rootpw vs. normal Bind as rootdn (typically when rootdn names an entry):
>>     config, bdb, null, sql, overlay retcode (I think):
>>         Try rootpw first, then if failure try normal Bind (even if
>>         rootpw exists but the Bind password does not match it).
>>     ldif:
>>         Do not try rootpw if rootdn names an existing entry.
>>     meta:
>>         Fail if rootpw is missing or does not match, more complicated
>>         otherwise.
>>     monitor:
>>         Fine - there are no entries with passwords.
> 
> (yet :)
> 
> I discovered that back-monitor may benefit from having a rootdn because
> this provides a means to easily workaround any ACLs.  The availability
> of rootpw is also important because I ran into few cases where no other
> means to authenticate were available, and all in all this feature (I
> mean: rootdn w/ rootpw comes for free from the database infrastructure).

Don't you do this in test043:

"# HACK: use the RootDN of the monitor database as UpdateDN so ACLs apply"