Bug in 0.7.13 nslcd (Still present in trunk)

[Tim <weirdit [at] gmail.com>]

I believe I've found a bug in nslcd.

Trying to login with pam, I was getting an "user has invalid username"
error message. I added some debugging statements, and discovered the
"value" (pam.c validate_user function) was getting a strange value.
For a user with uid=linux in the ldap, it was getting value =
"mber=10062" which I immediately recognised as the end of
uidNumber=10062 attribute. For some reason it was fetching the wrong
attribute and thinking it was the username.
I worked backwards and value was being set by myldap_get_rdn_value
(after the comment /* get the "real" username */. (Sorry, would give
line numbers, but I've messed with the src now, all this is less
relevant than the bug fix).

Digging into myldap.c I found where the bug is.
find_rdn_value (myldap.c line 1433, version 0.7.13)
It checks that the start of the attribute matches the attribute we are
looking for. so the start of uidNumber matches when looking for the
attribute uid. This is ok. However done on line 1450, we check for an
equals sign next, to make sure we actually did find the attribute.
Fail. So we should then continue searching, instead we increment j
again and look for spaces to skip.
I believe this bug may not have come up before depending on how dn's
are stored. Most people store them as uid=123,dc=example,dc=com
however we are choosing to store them as
uidNumber=100034,dc=example,dc=com so it needs to fetch the uid
attribute.

The simple fix is to add in a continue statement.
So from line 1449

    /* ensure that we found an equals sign now */
    if (exploded_rdn[i][j]!='=')
    j++;

Becomes
    /* ensure that we found an equals sign now */
    if (exploded_rdn[i][j]!='=')
      continue;
    j++;

It then fails to find the uid in the exploded_dn, returns back into
the validate_user function in pam.c and does the needed work to fetch
to correct uid attribute.

It appears the bug is still in trunk of 0.8.3, myldap.c line 1453.

Apologies for not producing a proper diff. If you really need one for
this one liner, then let me know and I'll checkout both 0.7.13 and
0.8.13 and patch against them.

Thanks

Tim

btw, I was trying to debug with gdb, but I think maybe nslcd has
threads because it was proving very difficult to debug with gdb. What
is your normal method of debugging?
-- 
Timothy White - Somewhere in Australia
-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users