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

[ando@sys-net.it]

>> 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.
>
> (But aging out the administrator's password is a good way to lock yourself
> out
> of your system. Note that ppolicy always lets the rootdn past all policy
> checks
> for this reason.)
>
>> 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>).
>
> I disagree; this behavior has existed for a long time and there are
> probably
> people out there relying on it. This isn't much different from the fact
> that
> userPassword itself is multivalued. I seem to recall this behavior being
> documented somewhere, can't find the reference at the moment.

In any case, I see this as a bug rather than a feature.  The rootdn should
be a special identity, which in many cases is only used for internal
purposes.  If the rootdn is outside the scope of the database, then it's
not going to impact that database's be_bind(); if it's inside and it
doesn't have a rootpw, then it might make sense that an entry with that DN
exists, so that setting the rootpw could represent a means to workaround
forgetting the entry's password or database corruptions.  But checking
both really sounds a bit too cumbersome.  The we should allow multiple
rootpw values...

It's another question whether we should preserve or not this behavior for
backward compatibility; in that case, all we need to do is handle the
non-success, non-continue case in the switch and let it pass thru.  But
I'd require this at least to be explicitly enabled.

>> 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.
>
> I don't think these cases merit any special consideration.

I disagree.  They sound academic, but they could pose a threat.  I don't
mean the code should obnoxiously check for this, but the possibility
should be documented.  The "right" solution would be to protect the
identity of the rootdn with ACLs, so that regular users cannot add/modify
it.

>> - 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.
>
> If "bind on" means "accept Simple Bind with any password" then rootpw
> should be
> irrelevant here. Of course, for back-null the rootdn itself is pretty
> meaningless.

Yes.  The idea is to provide a simple means to allow binding with some
identity without the need to configure anything special - that's the role
of back-null, basically.  What I essentially did was to take all backends
that implement BI_op_bind and add the possibility to exploit the rootdn,
which is allowed by the configuration anyway.  I think this is better than
letting people define rootdn/rootpw in the configuration and not using it.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------