Re: (ITS#5008) Do you have the win32 version of OpenLDAP
by h.b.furuseth＠usit.uio.no
caojunliang(a)huawei.com writes:
> I want to know whether or not the win32 version of OpenLDAP exsits.
Please take this to the mailinglist openldap-software(a)openldap.org.
The Issue Tracking System is for bug reports etc, not for help requests.
This ITS will be closed.
--
Regards,
Hallvard
15 years, 9 months
(ITS#5010) broken ber_encode_oid/ber_decode_oid()
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD
OS:
URL: http://folk.uio.no/hbf/OpenLDAP/oid-encdec.txt
Submission from: (NULL) (129.240.202.105)
Submitted by: hallvard
The 40*X+Y rule for first 2 components is decoded wrong, it should be
X = val < 80 ? val/40 : 2 # X = 0, 1 or 2
Y = val - 40*X # Y is unlimited when X==2, <40 otherwise
See X.690 8.19.4: ... (X*40) + Y: NOTE - This packing of the first two
object identifier components recognizes that only three values are
allocated from the root node, and at most 39 subsequent values from
nodes reached by X = 0 and X = 1.
40*X+Y can take more than one octet.
The functions allow buffer overruns. ber_decode_oid() if the oid has
many small components. ber_encode_oid() for negative input (which
becomes a large ulong), or if sizeof(long) == 8. The latter can just as
easily be avoided by producing the bytes backwards and then reversing.
They do not check much for invalid input or too large values. Possibly
they ought to be a bit paranoid about that since they are used for
certificates, I don't know. E.g. check that the BER encoding has
"fewest possible octets" (X.690 8.19.2), i.e. no initial 0x80 in
subidentifiers. ber_encode_oid() seems a bit strange about which errors
it accepts and which ones it rejects. E.g. garbage after first 2
components is OK.
The "assert(foo != NULL)"s are after "der = foo->bv_val":-)
I enclose untested new versions. Will test and commit when I have time
if someone says OK, but it depends e.g. on how paranoid the routines
should or should not be. Or if they should trust the ber values to end
with \0, for that matter.
Finally, libldap/tls.c does not check if ber_decode_oid() fails.
15 years, 9 months
Re: (ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com
Thinking about this further, it looks like the manpage is really
deferring to 'ldapsearch --help' since that is where the meat of the
documentation is. There is some potential confusion here I think.
What if the manpage just refers the reader to 'ldapsearch --help' for
complete information?
--
Puryear Information Technology, LLC
Baton Rouge, LA * 225-706-8414
http://www.puryear-it.com
Author:
"Best Practices for Managing Linux and UNIX Servers"
"Spam Fighting and Email Security in the 21st Century"
Download your free copies:
http://www.puryear-it.com/pubs/ebooks/
15 years, 9 months
Re: (ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com
By the way, I did verify that -C does work. It simply isn't in the manpage.
Also, a quick grep of the binary:
[root@samba openldap]# strings /usr/bin/ldapsearch | grep -- -C
-C chase referrals (anonymously)
This is a low priority documentation bug only. The binary works fine.
--
Puryear Information Technology, LLC
Baton Rouge, LA * 225-706-8414
http://www.puryear-it.com
Author:
"Best Practices for Managing Linux and UNIX Servers"
"Spam Fighting and Email Security in the 21st Century"
Download your free copies:
http://www.puryear-it.com/pubs/ebooks/
15 years, 9 months
(ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com
Full_Name: Dustin Puryear
Version: 2.213-7
OS: CentOS 4.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (72.242.176.166)
The -C flag is not in the ldapsearch manpage.
# rpm -q -a | grep openldap
openldap-2.2.13-7.4E
openldap-devel-2.2.13-7.4E
openldap-servers-2.2.13-7.4E
openldap-clients-2.2.13-7.4E
#
# man ldapsearch | grep -- -C
#
Alias info is there:
# man ldapsearch | grep -- -a
[-s base|one|sub] [-a never|always|search|find] [-l timelimit]
ldapsearch is a shell-accessible interface to the ldap_search(3)
-a never|always|search|find
audio:< file:///tmp/ldapsearch-audio-a19924
jpegPhoto:< file:///tmp/ldapsearch-jpegPhoto-a19924
#
# man ldapsearch | tail
The OpenLDAP Project <http://www.openldap.org/>
ACKNOWLEDGEMENTS
OpenLDAP is developed and maintained by The OpenLDAP Project
(http://www.openldap.org/). OpenLDAP is derived from University of
Michigan LDAP 3.3 Release.
OpenLDAP 2.2.13 2004/06/10 LDAPSEARCH(1)
#
# cat /etc/redhat-release
CentOS release 4.3 (Final)
#
15 years, 9 months
Re: (ITS#5005) test017 fails
by ando＠sys-net.it
dieter(a)dkluenter.de wrote:
> the patch fails, this is the patch reject file:
That's probably because you cut'n'pasted from the email, where the tabs
were probably replaced by whitespaces. I'll apply that fix if anyone
confirms that cookie is legal at all.
Cheers, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 9 months
Re: (ITS#5005) test017 fails
by dieter＠dkluenter.de
Quanah Gibson-Mount <quanah(a)zimbra.com> writes:
> --On June 8, 2007 6:43:50 PM +0000 dieter(a)dkluenter.de wrote:
>
>> Full_Name: Dieter Kluenter
>> Version: HEAD
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (84.142.196.121)
>>
>>
>> here the output of test017 logfiles
>>
>> ---slapd.1.log----------------
>> ber_scanf fmt (}) ber:
>> <= get_ctrls: n=1 rc=2 err="Sync control : cookie parsing error"
>> send_ldap_result: conn=7 op=1 p=3
>> send_ldap_result: err=2 matched="" text="Sync control : cookie parsing
>> error" send_ldap_response: msgid=2 tag=101 err=2
>
> Hm, is this possibly related to the fix for ITS#4977? If you revert
> that checkin for syncprov.c today, does the test pass?
>
>
> <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov....>
Unfortunately no chance, still the same error.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
15 years, 9 months
Re: (ITS#5005) test017 fails
by dieter＠dkluenter.de
Pierangelo Masarati <ando(a)sys-net.it> writes:
> dieter(a)dkluenter.de wrote:
>
> The problem is in slap_parse_sync_cookie(); when no cookie is passed, a
> string containing "rid=001" is parsed. The parser expects it to end
> with a comma. If passing "rid=001" is correct, the fix is trivial:
> instead of checking for (*next != ','), check for (*next && *next != ',').
>
> Index: servers/slapd/ldapsync.c
> ===================================================================
> RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/ldapsync.c,v
> retrieving revision 1.42
> diff -u -r1.42 ldapsync.c
> --- servers/slapd/ldapsync.c 18 May 2007 12:46:52 -0000 1.42
> +++ servers/slapd/ldapsync.c 9 Jun 2007 09:42:24 -0000
> @@ -180,7 +180,10 @@
> if ( !strncmp( next, "rid=", STRLENOF("rid=") )) {
> rid_ptr = next;
> cookie->rid = strtoul( &rid_ptr[ STRLENOF(
> "rid=" ) ], &next, 10 );
> - if ( next == rid_ptr || next > end || *next !=
> ',' ) {
> + if ( next == rid_ptr
> + || next > end
> + || ( *next && *next != ',' ) )
> + {
> return -1;
> }
> if ( *next == ',' ) {
> @@ -194,7 +197,10 @@
> if ( !strncmp( next, "sid=", STRLENOF("sid=") )) {
> rid_ptr = next;
> cookie->sid = strtoul( &rid_ptr[ STRLENOF(
> "sid=" ) ], &next, 16 );
> - if ( next == rid_ptr || next > end || *next !=
> ',' ) {
> + if ( next == rid_ptr
> + || next > end
> + || ( *next && *next != ',' ) )
> + {
> return -1;
> }
> if ( *next == ',' ) {
>
> I'm not committing this fix because I'm not sure it doesn't break
> anything else.
the patch fails, this is the patch reject file:
---ldapsync.c.rej -------------------------------
***************
*** 180,186 ****
if ( !strncmp( next, "rid=", STRLENOF("rid=") )) {
rid_ptr = next;
cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 );
- if ( next == rid_ptr || next > end || *next != ',' ) {
return -1;
}
if ( *next == ',' ) {
--- 180,189 ----
if ( !strncmp( next, "rid=", STRLENOF("rid=") )) {
rid_ptr = next;
cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 );
+ if ( next == rid_ptr
+ || next > end
+ || ( *next && *next != ',' ) )
+ {
return -1;
}
if ( *next == ',' ) {
***************
*** 194,200 ****
if ( !strncmp( next, "sid=", STRLENOF("sid=") )) {
rid_ptr = next;
cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ]. &next, 16 );
- if ( next == rid_ptr || next > end || *next != ',' ) {
return -1;
}
if ( *next == ',' ) {
--- 197,206 ----
if ( !strncmp( next, "sid=", STRLENOF("sid=") )) {
rid_ptr = next;
cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ]. &next, 16 );
+ if ( next == rid_ptr
+ || next > end
+ || ( *next && *next != ',' ) )
+ {
return -1;
}
if ( *next == ',' ) {
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
15 years, 9 months
Re: (ITS#4936) default modulepath
by ando＠sys-net.it
> No, they are installed in $(moduledir), which depends on LDAP_LIBEXECDIR
> and --with-subdir. So, put that in some C variable or #define.
Yes, I figured that out. I'll fix this later.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 9 months
