[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(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.