(ITS#4962) inconsistent Bind(rootdn) behavior

Full_Name: Hallvard B Furuseth
Version: HEAD, RE23
OS: 
URL: 
Submission from: (NULL) (129.240.202.105)
Submitted by: hallvard


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.
    (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.
The manpage is (fortunately unclear on
what happens in this case.

Check if op->orb_method == LDAP_AUTH_SIMPLE:
    Yes: config, bdb, meta, monitor.
    No:  ldif, null, sql, overlay retcode.

Set op->orb_edn (op->oq_bind.rb_edn) from be_root_dn()
on success:
    config, bdb, monitor, sql.

Set op->orb_edn on failure:
    bdb: Sometimes, from &e->e_name.
    sql: Always, from op->o_req_ndn.

Set rs->sr_err = LDAP_SUCCESS on success:
    ldif, meta

Reset rs->sr_text:
    meta

Which behavior is right?  I'm wondering if Bind should fail
if rootpw
exists but the Bind password does not match it.

In any case, methinks we need a be_rootpw_bind(op, rs)
function which
takes care of this consistently, so bi_op_bind in most cases
can just do
    if (be_rootpw_bind(op, rs)) return rs->sr_err;
If needed it could accept rs==NULL to just check the
password - like
be_isroot_pw() but with more return codes to distinguish
different
cases.