Re: (ITS#8714) RFE: Sendout EXTENDED operation message in back-sock

[hyc@symas.com]

Michael Str=C3=B6der wrote:
> Howard Chu wrote:
>> michael@stroeder.com wrote:
>>> +    /* write out the request to the extended process */
>>> +    fprintf( fp, "EXTENDED\n" );
>>> +    fprintf( fp, "msgid: %ld\n", (long) op->o_msgid );
>>> +    sock_print_conn( fp, op->o_conn, si );
>>> +    sock_print_suffixes( fp, op->o_bd );
>>> +    fprintf( fp, "oid: %s\n", op->ore_reqoid.bv_val );
>>> +  if (op->ore_reqdata) {
>>> +        fprintf( fp, "valuelen: %lu\n", op->ore_reqdata->bv_len );
>>> +        fprintf( fp, "value: %s\n", op->ore_reqdata->bv_val );
>>> +    }
>>> +    fprintf( fp, "\n" );
>>
>> This isn't safe. The reqdata is binary, not a nul-terminated C string.=
 I suppose you
>> could hex or base64-encode it instead.
>=20
> Frankly I don't understand.
>=20
> I considered using base64 but I wanted to stick to what's already done =
in back-sock.
>=20
> See openldap/servers/slapd/back-sock/bind.c for the password value whic=
h is also an
> arbitrary OctetString:
>=20
> 	/* write out the request to the bind process */
> [..]
> 	fprintf( fp, "credlen: %lu\n", op->oq_bind.rb_cred.bv_len );
> 	fprintf( fp, "cred: %s\n", op->oq_bind.rb_cred.bv_val ); /* XXX */
> 	fprintf( fp, "\n" );
>=20
> The above should also work with null-bytes, shoudn't it?

No, it's a bug. Probably a benign bug because it's difficult for users to=
=20
create passwords with embedded NULs.

--=20
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/