llg@portaildulibre.fr wrote:
Le 02/02/2012 20:32, hyc@symas.com a écrit :
jiashun.qian@atos.net wrote:
Full_Name: Jiashun QIAN Version: 2.4.28 OS: CentOS 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.115.60.180)
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.
servers/slapd/back-perl/modify.c 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.