[Date Prev][Date Next]
(ITS#4962) inconsistent Bind(rootdn) behavior
Full_Name: Hallvard B Furuseth
Version: HEAD, RE23
Submission from: (NULL) (220.127.116.11)
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:
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).
Do not try rootpw if rootdn names an existing entry.
Fail if rootpw is missing or does not match, more complicated
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:
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