[Pkg-samba-maint] Bug#532859: closed by Christian Perrier <bubulle at debian.org> (Re: Bug#532859: sambaPwdLastSet became a mandatory ldapsam attribute with no warning)

[Josip Rodin]

On Sun, Aug 16, 2009 at 08:09:27AM +0000, Debian Bug Tracking System wrote:
> > As it turns out, they didn't have the sambaPwdLastSet attribute in their
> > LDAP entries. This was easy to fix, but still a regression from Samba 3.0.
> > Nothing actually told me that the attribute was missing, I concluded it from
> > reading the code... it seems like this part of the code is the culprit:
> 
> 
> As it was just pointed today by Oded Naveh, this change (prevent
> logging from clients when sambaPwdLastSet is not set), is an upstream
> change that was documented..;and indeed was even there in etch's
> version (the change appeared in 3.0.2).

This entry in WHATSNEW.txt needs to go into NEWS.Debian in order for us who
upgrade the package to see it, surely? Nevertheless, see below...

> I don't really understand why and how things were working for you in
> etch but, indeed, impossible logins from accounts that don't have
> sambaPwdLastSet is a "normal" expected behaviour ?? post 3.0.2 samba
> versions.

>                 if (((acct_ctrl & (ACB_WSTRUST|ACB_SVRTRUST)) == 0) && (last_set_time == 0)) {
> In the old version from etch, that looked like this:
>                 if (must_change_time == 0 && last_set_time != 0) {

Well you can see from these that the logic had changed. Their handling of
the last_set_time clearly differs, one checks == 0 and the other != 0.
And I've told you earlier what the actual behaviour in the wild was - the
etch version didn't forbid logins, the lenny version did.

I read the text pasted from WHATSNEW.txt and it says "sambaPwdLastSet
attribute in ldapsam" with the value of "zero (0)". In my case, there was
*no* attribute and no value, not a zero (0) value. If these two situations
are treated as equal, then this needs to be pointed out to the unwitting
user because it certainly isn't clear now. If someone says "zero" and then
clarifies with "0" in parenthesis, then a reasonable reading is that it is
an inclusive definition, not a vague definition that may also implicitly
include 'null', 'false', 'missing', etc.

All in all this is just another bug in my series of ldapsam complaints. The
code expects a certain strict data set in LDAP, yet it does very few if any
pre-emptive consistency checks. Coupled with changing requirements like we
see in this case, that's a recipe for failure when met with random user data.

-- 
     2. That which causes joy or happiness.