[Date Prev][Date Next]
Re: (ITS#7149) Back-perl, Back-shell and Binary Data
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#7149) Back-perl, Back-shell and Binary Data
- From: email@example.com
- Date: Thu, 2 Feb 2012 20:44:34 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> Le 02/02/2012 20:32, firstname.lastname@example.org a écrit :
>> email@example.com wrote:
>>> Full_Name: Jiashun QIAN
>>> Version: 2.4.28
>>> OS: CentOS 6
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (188.8.131.52)
>>> The backend shell and the backend perl can't handle some binary data.
>>> This occurs only with MODIFY because when ADD the binary data is encoded in
>>> base64 but not MODIFY.
>>> The binary data is truncated when if it contains \0. In fact, data is stored in
>>> a linked list of char * and treated as characters.
>>> XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 )));
>>> The type of mods->sm_values[i].bv_val is char*.
>>> To handle the binary data, for back-perl, just change another function mXPUSHp,
>>> which we can put the exacte length of mod->sm_values[i].bv_val as parameter,
>>> it's mod->sm_values[i].bv_len. So it will push the total data.
>> That is obviously the wrong approach. Since these backends communicate using
>> LDIF, binary values should be base64 encoded according to the LDIF rules.
> The input LDIF file for ldap_modify contains base64 encoded
> usercertificate, but back-perl receives binary data.
> This behaviour only occured with modification action : with add action,
> certificate is received base64 encoded.
Yes, I already understood that. You're still not understanding what I said.
Your patch should do the appropriate checks for binary data and do the proper
base64 encoding for the modify values that back-perl (or back-shell) sends to
the perl module (or shell script).
This has nothing to do with the input LDIF file, this is about how slapd
transmits internal data from a backend to the external perl or shell scripts.
>> Thanks for the patch, but we can't merge it since the provided solution is wrong.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/