12:48 a.m.
This is a multi-part message in MIME format.
--------------070001090703090002060300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi,
any news concerning integration of this patch ?
Thanks
Laurent Le Grandois
Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =E9crit :
--=20
Cordialement,
*Laurent Le Grandois <http://people.portaildulibre.fr/%7Ellg/qr-code.png>=
*
Architecte Open Source
Campus AtoS - River Ouest
Pacific 3 Sud 8
+33 (0) 1 73 26 16 32
+33 (0) 6 70 01 25 61
80, Quai Voltaire 95877 Bezons Cedex
Signature IOC <http://www.atos.net>
--------------070001090703090002060300
Content-Type: multipart/related;
boundary="------------050007050004070007020800"
--------------050007050004070007020800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
any news concerning integration of this patch ? <br>
<br>
Thanks<br>
<br>
Laurent Le Grandois<br>
<br>
<br>
Le 06/02/2012 18:23, <a class="moz-txt-link-abbreviated"
href="mailto:jiashun.qian@atos.net">jiashun.qian@atos.net</a> a
écrit :
<blockquote
cite="mid:201202061723.q16HNLgD077070@boole.openldap.org"
type="cite">
<pre wrap="">Now the new patch encode the binary data to base64 by
using slap_ad_is_binary to check if it's binary data, and using lutil_b64_ntop for the
encode.
*** ../openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11-25
19:52:29.000000000 +0100
--- servers/slapd/back-perl/modify.c 2012-02-06 17:41:44.638861010 +0100
***************
*** 16,21 ****
--- 16,22 ----
*/
#include "perl_back.h"
+ #include "lutil.h"
int
perl_back_modify(
***************
*** 26,31 ****
--- 27,33 ----
Modifications *modlist = op->orm_modlist;
int count;
int i;
+ struct berval b64_data;
PERL_SET_CONTEXT( PERL_INTERPRETER );
ldap_pvt_thread_mutex_lock( &perl_interpreter_mutex );
***************
*** 61,67 ****
mods->sm_values != NULL &&
mods->sm_values[i].bv_val != NULL;
i++ )
{
! XPUSHs(sv_2mortal(newSVpv(
mods->sm_values[i].bv_val, 0 )));
}
/* Fix delete attrib without value. */
--- 63,80 ----
mods->sm_values != NULL &&
mods->sm_values[i].bv_val != NULL;
i++ )
{
! if ( slap_ad_is_binary(mods->sm_desc) ) {
! b64_data.bv_len =
LUTIL_BASE64_ENCODE_LEN(mods->sm_values[i].bv_len) + 1;
! b64_data.bv_val = ber_memalloc( b64_data.bv_len +
1 );
! b64_data.bv_len = lutil_b64_ntop(
! (unsigned char *)
mods->sm_values[i].bv_val,
! mods->sm_values[i].bv_len,
! b64_data.bv_val, b64_data.bv_len
);
! XPUSHs(sv_2mortal(newSVpv( b64_data.bv_val, 0
)));
! ber_memfree( b64_data.bv_val );
! } else {
! XPUSHs(sv_2mortal(newSVpv(
mods->sm_values[i].bv_val, 0 )));
! }
}
/* Fix delete attrib without value. */
*** ../openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11-25
19:52:29.000000000 +0100
--- servers/slapd/back-shell/modify.c 2012-02-06 17:40:14.861837487 +0100
***************
*** 37,42 ****
--- 37,43 ----
#include "slap.h"
#include "shell.h"
+ #include "lutil.h"
int
shell_back_modify(
***************
*** 50,55 ****
--- 51,57 ----
Entry e;
FILE *rfp, *wfp;
int i;
+ struct berval b64_data;
if ( si->si_modify == NULL ) {
send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM,
***************
*** 105,112 ****
if( mod->sm_values != NULL ) {
for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) {
! fprintf( wfp, "%s: %s\n",
mod->sm_desc->ad_cname.bv_val,
! mod->sm_values[i].bv_val /* binary! */ );
}
}
--- 107,126 ----
if( mod->sm_values != NULL ) {
for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) {
! if ( slap_ad_is_binary(mod->sm_desc) ) {
! b64_data.bv_len =
LUTIL_BASE64_ENCODE_LEN(mod->sm_values[i].bv_len) + 1;
! b64_data.bv_val = ber_memalloc( b64_data.bv_len +
1 );
! b64_data.bv_len = lutil_b64_ntop(
! (unsigned char *)
mod->sm_values[i].bv_val,
! mod->sm_values[i].bv_len,
! b64_data.bv_val, b64_data.bv_len
);
! fprintf( wfp, "%s: %s\n",
mod->sm_desc->ad_cname.bv_val,
! b64_data.bv_val );
! ber_memfree( b64_data.bv_val );
! } else {
! fprintf( wfp, "%s: %s\n",
mod->sm_desc->ad_cname.bv_val,
! mod->sm_values[i].bv_val );
! }
}
}
________________________________________
De : <a class="moz-txt-link-abbreviated"
href="mailto:openldap-bugs-bounces@OpenLDAP.org">openldap-bugs-bounces@OpenLDAP.org</a>
[<a class="moz-txt-link-abbreviated"
href="mailto:openldap-bugs-bounces@OpenLDAP.org">openldap-bugs-bounces@OpenLDAP.org</a>]
de la part de <a class="moz-txt-link-abbreviated"
href="mailto:hyc@symas.com">hyc@symas.com</a> [<a
class="moz-txt-link-abbreviated"
href="mailto:hyc@symas.com">hyc@symas.com</a>]
Date d'envoi : jeudi 2 février 2012 21:44
À : <a class="moz-txt-link-abbreviated"
href="mailto:openldap-its@openldap.org">openldap-its@openldap.org</a>
Objet : Re: (ITS#7149) Back-perl, Back-shell and Binary Data
<a class="moz-txt-link-abbreviated"
href="mailto:llg@portaildulibre.fr">llg@portaildulibre.fr</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Le 02/02/2012 20:32, <a
class="moz-txt-link-abbreviated"
href="mailto:hyc@symas.com">hyc@symas.com</a> a écrit :
</pre>
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated"
href="mailto:jiashun.qian@atos.net">jiashun.qian@atos.net</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Full_Name: Jiashun QIAN
Version: 2.4.28
OS: CentOS 6
URL: <a class="moz-txt-link-freetext"
href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o...
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.
</pre>
</blockquote>
<pre wrap="">That is obviously the wrong approach. Since these
backends communicate using
LDIF, binary values should be base64 encoded according to the LDIF rules.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Thanks for the patch, but we can't merge it
since the provided solution is wrong.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
--
-- Howard Chu
CTO, Symas Corp. <a class="moz-txt-link-freetext"
href="http://www.symas.com">http://www.symas.com</a>
Director, Highland Sun <a class="moz-txt-link-freetext"
href="http://highlandsun.com/hyc/">http://highlandsun.com/hy...
Chief Architect, OpenLDAP <a class="moz-txt-link-freetext"
href="http://www.openldap.org/project/">http://www.openldap....
________________________________
Ce message et les pièces jointes sont confidentiels et
réservés à l'usage exclusif de ses destinataires. Il
peut également être protégé par le secret
professionnel. Si vous recevez ce message par erreur, merci d'en avertir
immédiatement l'expéditeur et de le détruire.
L'intégrité du message ne pouvant être
assurée sur Internet, la responsabilité du groupe Atos ne pourra
être engagée quant au contenu de ce message. Bien que les meilleurs
efforts soient faits pour maintenir cette transmission exempte de tout virus,
l'expéditeur ne donne aucune garantie à cet égard et
sa responsabilité ne saurait être engagée pour tout
dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the
addressee; it may also be privileged. If you receive this e-mail in error, please notify
the sender immediately and destroy it. As its integrity cannot be secured on the Internet,
the Atos group liability cannot be triggered for the message content. Although the sender
endeavors to maintain a computer virus-free network, the sender does not warrant that this
transmission is virus-free and will not be liable for any damages resulting from any virus
transmitted.
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div class="moz-signature"><br>
<font face="CMU Sans Serif"> Cordialement,<br>
<img src="cid:part1.08020906.06070706@atos.net"
border="0"><br>
<br>
<b><a
href="http://people.portaildulibre.fr/%7Ellg/qr-code.png">Laurent
Le Grandois</a></b><br>
<font style="font-size: 8pt;"> <br>
Architecte Open Source<br>
<br>
Campus AtoS - River Ouest<br>
Pacific 3 Sud 8<br>
+33 (0) 1 73 26 16 32<br>
+33 (0) 6 70 01 25 61<br>
80, Quai Voltaire 95877 Bezons Cedex<br>
</font> </font> <a href="http://www.atos.net">
<img
src="cid:part3.07050008.03070309@atos.net" alt="Signature
IOC" border="0"></a> </div>
</div>
</body>
</html>
--------------050007050004070007020800
Content-Type: image/gif;
name="blue_strip.gif"
Content-Transfer-Encoding: base64
Content-ID: <part1.08020906.06070706(a)atos.net>
Content-Disposition: inline;
filename="blue_strip.gif"
R0lGODlhgAADAKIAAABnoX+z0ECNuZ/G3P///wAAAAAAAAAAACH5BAEAAAQALAAAAACAAAMA
AAMTCLrc/jDKSau9OOvNu/9gKI5OAgA7
--------------050007050004070007020800
Content-Type: image/gif;
name="atos_logo_small.gif"
Content-Transfer-Encoding: base64
Content-ID: <part3.07050008.03070309(a)atos.net>
Content-Disposition: inline;
filename="atos_logo_small.gif"
R0lGODlhgAAlAMQAAABnoX9/f7/Z53+z0ECNuRBxp9/s8+/1+Z/G3M/i7SB6rTCEs2CgxK/P
4nCqyo+81lCXvt/f37+/v////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACH5BAEAABMALAAAAACAACUAAAX/YCCOZGmeaKqubOu+6CTPdG3feK7vfO//wKBwSCwaj8ik
cslsOp/QqHRKrVqv2Kx2y+16fQaBOPHlAc7oNACRE6gF0MODoD4XCA52uVZXE9pvTwMFfXV7
fIVoBjhuaXBMB3SJaoc0AwOSfQ+MgT0HlwMNizgMk2oFlTULiQs0CQSwq2kLsLU1nwwTpbN6
rnUKeWIImX+pMganaqMTjaZnNA2EooUEyxMOark1A2jFxthoELtoDjPNzjPgqOB9BWQymQAK
N9xn3qkKaQgNavMy56Zk1APwJ18id/DS+NvWzdiEBGkKHJhgEM07A6DGnWEA6hKzNAMmqIFA
SOHEeAC0/90w8C4Vu5QyXsKsAfARjYprAE4wIAtNSI1nFPRyaKPkmQYyIEa0UbMGgjc6Jxzo
CUAiQDTAWhKdwA8Nqhk4ASCl0ZQGhFkf08xQioYNyn4DrKXSWG7GwI00O81Qo0dNy7Nock11
xmBiqgNGAWhFFtHwP70P1RimqvJpQ4GJ2409ZDmoDapryEI+t/Cu4sdeaXwKW0frF8DOwol2
NPtMq2OnyESt0YABa3uHDsSu47gsajSWTj14kOaejQZvAcjl0nn4mU3Hz9iUoWbz4EkQeESD
3AX08Ntp0WyfQPXe90JDc8hcv4UxmgZi8uvPPArgZhnVAYCdDO8R14Np9GnB3K1lpKiBHUAq
4cbXNpnBZEBWOCTAXxlUxcdbPxKmMSACvxHQwEQGPJCZRLp4BUEoYjwAGxro1SdAgPhleBUC
AhQYFAEVWgfHVc4keIVpat0QnXZdmWJeIno8OUldXSCJnJKJwCFTHWxY2c87BwA1SQEeauEl
ADgsCcAjDZTYkgFiBhVSDSlKaYcD09mon3467pmfY8x0hECeBzQwAAMEXOKaDQcI8EBHAzyw
qBchAAA7
--------------050007050004070007020800--
--------------070001090703090002060300--
Now the new patch encode the binary data to base64 by using
slap_ad_is_=
binary to check if it's binary data, and using lutil_b64_ntop for
the enc=
ode.
*** ../openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11=
-25
19:52:29.000000000 +0100
--- servers/slapd/back-perl/modify.c 2012-02-06 17:41:44.638861010
+=
0100
***************
*** 16,21 ****
--- 16,22 ----
*/
#include "perl_back.h"
+ #include "lutil.h"
int
perl_back_modify(
***************
*** 26,31 ****
--- 27,33 ----
Modifications *modlist =3D op->orm_modlist;
int count;
int i;
+ struct berval b64_data;
PERL_SET_CONTEXT( PERL_INTERPRETER );
ldap_pvt_thread_mutex_lock(&perl_interpreter_mutex );
***************
*** 61,67 ****
mods->sm_values !=3D NULL&& mods->sm_=
values[i].bv_val !=3D NULL;
i++ )
{
! XPUSHs(sv_2mortal(newSVpv( mods->sm_val=
ues[i].bv_val, 0 )));
}
/* Fix delete attrib without value. */
--- 63,80 ----
mods->sm_values !=3D NULL&& mods->sm_=
values[i].bv_val !=3D NULL;
i++ )
{
! if ( slap_ad_is_binary(mods->sm_desc) )=
{
! b64_data.bv_len =3D
LUTIL_BASE6=
4_ENCODE_LEN(mods->sm_values[i].bv_len) + 1;
! b64_data.bv_val =3D
ber_memallo=
c( b64_data.bv_len + 1 );
! b64_data.bv_len =3D
lutil_b64_n=
top(
! (unsigned
char =
*) mods->sm_values[i].bv_val,
!
mods->sm_values=
[i].bv_len,
!
b64_data.bv_val=
, b64_data.bv_len );
! XPUSHs(sv_2mortal(newSVpv(
b64_=
data.bv_val, 0 )));
! ber_memfree( b64_data.bv_val
);
! } else {
! XPUSHs(sv_2mortal(newSVpv( mods=
->sm_values[i].bv_val, 0 )));
! }
}
/* Fix delete attrib without value. */
*** ../openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11=
-25
19:52:29.000000000 +0100
--- servers/slapd/back-shell/modify.c 2012-02-06 17:40:14.861837487
+=
0100
***************
*** 37,42 ****
--- 37,43 ----
#include "slap.h"
#include "shell.h"
+ #include "lutil.h"
int
shell_back_modify(
***************
*** 50,55 ****
--- 51,57 ----
Entry e;
FILE *rfp, *wfp;
int i;
+ struct berval b64_data;
if ( si->si_modify =3D=3D NULL ) {
send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM,
***************
*** 105,112 ****
if( mod->sm_values !=3D NULL ) {
for ( i =3D 0; mod->sm_values[i].bv_val !=3D N=
ULL;
i++ ) {
! fprintf( wfp, "%s: %s\n",
mod->sm_desc-=
ad_cname.bv_val,
! mod->sm_values[i].bv_val /* bin=
ary! */
);
}
}
--- 107,126 ----
if( mod->sm_values !=3D NULL ) {
for ( i =3D 0; mod->sm_values[i].bv_val !=3D N=
ULL;
i++ ) {
! if (
slap_ad_is_binary(mod->sm_desc) ) =
{
! b64_data.bv_len =3D
LUTIL_BASE6=
4_ENCODE_LEN(mod->sm_values[i].bv_len) + 1;
! b64_data.bv_val =3D
ber_memallo=
c( b64_data.bv_len + 1 );
! b64_data.bv_len =3D
lutil_b64_n=
top(
! (unsigned
char =
*) mod->sm_values[i].bv_val,
!
mod->sm_values[=
i].bv_len,
!
b64_data.bv_val=
, b64_data.bv_len );
! fprintf( wfp, "%s:
%s\n", mod->=
sm_desc->ad_cname.bv_val,
> ! b64_data.bv_val );
> ! ber_memfree( b64_data.bv_val );
> ! } else {
! fprintf( wfp, "%s:
%s\n", mod->=
sm_desc->ad_cname.bv_val,
!
mod->sm_values[i].bv_va=
l );
! }
}
}
________________________________________
De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces@OpenLDAP=
.org] de
la part de hyc(a)symas.com [hyc(a)symas.com]
Date d'envoi : jeudi 2 f=E9vrier 2012 21:44
=C0 : openldap-its(a)openldap.org
Objet : Re: (ITS#7149) Back-perl, Back-shell and Binary Data
llg(a)portaildulibre.fr wrote:
> Le 02/02/2012 20:32, hyc(a)symas.com a =E9crit :
>> jiashun.qian(a)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 enc=
oded in
>>> base64 but not MODIFY.
>>>
>>> The binary data is truncated when if it contains \0. In fact, data i=
s
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 functi=
on mXPUSHp,
>>> which we can put the exacte length of
mod->sm_values[i].bv_val as pa=
rameter,
>>> it's mod->sm_values[i].bv_len. So it will push the
total data.
>> That is obviously the wrong approach. Since these backends communicat=
e
using
>> LDIF, binary values should be base64 encoded according to the
LDIF ru=
les.
> 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 s=
aid.
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)
se=
nds to
the perl module (or shell script).
This has nothing to do with the input LDIF file, this is about how slap=
d
transmits internal data from a backend to the external perl or shell
sc=
ripts.
>> Thanks for the patch, but we can't merge it since the provided soluti=
on 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/
________________________________
Ce message et les pi=E8ces jointes sont confidentiels et r=E9serv=E9s =E0=
l'usage exclusif de ses destinataires. Il peut =E9galement =EAtre prot=E9=
g=E9 par le secret professionnel. Si vous recevez ce message par erreur, =
merci d'en avertir imm=E9diatement l'exp=E9diteur et de le d=E9truire. L'=
int=E9grit=E9 du message ne pouvant =EAtre assur=E9e sur Internet, la res=
ponsabilit=E9 du groupe Atos ne pourra =EAtre engag=E9e quant au contenu =
de ce message. Bien que les meilleurs efforts soient faits pour maintenir=
cette transmission exempte de tout virus, l'exp=E9diteur ne donne aucune=
garantie =E0 cet =E9gard et sa responsabilit=E9 ne saurait =EAtre engag=E9=
e pour tout dommage r=E9sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended so=
lely for
the addressee; it may also be privileged. If you receive this e-=
mail in error, please notify the sender immediately and destroy it. As it=
s integrity cannot be secured on the Internet, the Atos group liability c=
annot be triggered for the message content. Although the sender endeavors=
to maintain a computer virus-free network, the sender does not warrant t=
hat this transmission is virus-free and will not be liable for any damage=
s resulting from any virus transmitted.
4196
days inactive
4196
days old
0 comments
1 participants
participants (1)
-
Laurent.LeGrandoisļ¼ atos.net