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

[h.b.furuseth@usit.uio.no]

Pierangelo Masarati writes:
> Fixed in HEAD.  Now all backends honor rootdn bind (with slight
> variations; see back-null) through a common interface; in some cases,
> it's a blind fix (shell, perl, passwd).  I think I also fixed an
> inconsistency in back-bdb: as far as I understand, a bind with rootdn
> and incorrect rootdn password, or in case rootpw was null, originally
> passed through, probably either by mistake or to check if an analogous
> identity were defined in the database.  I consider this an
> inconsistency, but please review.

The back-bdb behavior sounds right: It should remain possible to have
the rootdn's password in an entry instead of in slapd.conf.  Among other
things, if the site has routines for regular password changes and "your
password is getting old" warnings, those will then cover rootdn as well.

Also it matches better the behavior if you Bind with a DN in one
database, which is the rootdn of another database.  The Bind operation
will work like a normal Bind since won't know that the DN is the rootdn
of the second database.

rootpw is a separate feature which can be convenient and which we in any
case need so it is possible to bind as rootdn even with an empty
database, or in backends which do not hold local entries.
(Briefly: rootdn for authorization, rootpw+rootdn for authentication.)

Anyway, that's why I suggested a be_rootpw_bind() rather than
be_rootdn_bind() function, it reflects this better.  (BTW, why a
switch() statement to check its return value instead of just an if()?)

OTOH if such an entry and rootpw both exist, I think it's a bug to
accept both passwords.  I think an existing rootpw should override the
entry's password, that's safest and least surprising (if the admin sets
rootpw and someone else manages to create an entry with dn: <rootdn>).

A few icky issues:

- if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside
  the database's DIT, it would be possible to create such an entry with
  a password.  We could advise people to use a DN outside the database
  suffix in this case, and/or accept 'rootpw' with no parameter as
  explicitly refusing Simple Bind with the rootdn.

- back-null's "bind on" (accept Simple Bind with any password).
  Maybe in this case it's best to treat rootdn without rootpw as
  "reject simple bind as rootdn", like your patch does.

  I don't know if there are overlays which can also make it sensible to
  do that, or if we need to anticipate such overlays.  retcode, maybe?

-- 
Regards,
Hallvard