Hello!
For lack of a Samba server (with attached Windows box) for testing
purposes I have reproduced the bug and tried the fix with the current
testing release 2:3.2.5-4, which runs on our production servers.
The bug still exists in 2:3.2.5-4 as packaged (not surprising).
The fix proposed by Simo solves the problem for me.
I have been looking into the background a bit in the meantime, and here is
what I have understood:
There is only a difference between the "N}" and "}" formatting codes if
the new password data is NULL. Passing an empty new password is a legal
use of the LDAP change password exop, and instructs the LDAP server to
generate a new password and return it with the response packet. However,
ber_printf'ing a NULL new password does not produce any data element
(the library silently ignores the NULL), so an extra null element must be
added as padding to balance the request packet. That is what the "N"
specifier does, it adds a null element iff a previous specifier (in our
case the "s" from the line above) is still waiting for data.
So here is a call that only the Samba people can make: Might there be a
future application of having the LDAP server generate a password?
If not then Simo's fix is superior to mine because then a NULL new
password must be the result of an error, and the malformed LDAP request
packet that his fix would produce in that case (and only in that case!)
would make the error apparent, whereas my fix would sliently gloss over it
and force creation of a new UNIX password that the user will never know.
If yes, and the "N" conversion specifier has compatibility issues, then
the best solution IMO would be to explicitly add padding as needed, e.g.
like this:
(this patch is for demonstration and has not been tested at runtime)
1732c1732,1733
< (ber_printf (ber, "n}") < 0)) {
---
> (!utf8_password && (ber_printf (ber, "n") < 0)) ||
> (ber_printf (ber, "}") < 0)) {
This change in itself does not actually do anything with the server
generated password, it just makes sure that no LDAP protocol error results
from having NULL as the new password value.
Either Simo's fix or the above proposal fixes the immediate problem of the
extra null element in the LDAP request.
Sincerely,
Ralph Rößner
--
Ralph Rößner
CAPCom AG < http://www.capcom.de >
Rundeturmstr. 10, 64283 Darmstadt, Germany
Phone +49 6151 155 900, Fax +49 6151 155 909
Vorstand: Luc Neumann (Vorsitzender)
Vorsitzender des Aufsichtsrats: Prof. Dr.-Ing. José L. Encarnação
Sitz der Gesellschaft: Darmstadt, Registergericht: Darmstadt HRB 8090
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
