openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 10 Feb '09

10 Feb '09

Pierangelo Masarati [mailto:ando@sys-net.it] wrote: > OpenLDAP clients do the following: > empty hostport, empty DN: localhost, default port > empty hostport, non-empty DN: SRV > what might be missing IMHO is: > use domain to specify SRV > however, I don't see any special need for it, as domain can always be > put in DN form. > I don't know if there's need for a form that asks to use SRV to discover > the server for the default SUFFIX. > In order to avoid issues, I recommend using something like > x-dnssrv={<domain>|<DN>} > where <DN> is restricted to the domain component sequence form. Ok, I start on this agreement ... So, is it a Good Thing (IYHO ;) to introduce this patch according the "followup 9" ?... One other possible solution could be (for example) to patch the ldap_connect_to_host() function in os-ip.c (around getaddrinfo() and ldap_pvt_gethostbyname_a() calls). However, samba (as an example) seems not to use it ... I think that the first solution remains the one who will have a minimal impact on the existing sources ... Michael Str.der wrote: > Frankly I'd vote against stuffing this into standard function > ldap_initialize(). Using this without further pre-caution (like > user-interaction) is broken in a similar way like chasing LDAPv3 > referrals at the client side. I also think myself that security aspects are important ; but in other hand, IMHO : it is of the responsibility of the DNS administrator to configure cleanly and to protect its systems of any corruption (and maybe also to the project BIND to improve tools allowing it). Although it is there, the advantage of the suggested solution ("followup 9") is as well as this patch can be located as well within the function ldap_initialize() as within another frontal function (according to what will be finally decided ;). --- PE

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

> Right, I did the same first with test017. I've now repeated with > test018, > which works fine since the intermediate message carries the sync > cookie. Ah, I never checked refreshOnly, as it's not an option I use often. Well, the issue about response controls needs to be solved at some point. In any case, proxying syncrepl this way should not be regular usage. I'm happy it helped sorting out some issues in the proxies. Fine for the liblber patch to be backed out, then. I can't test right now, but I don't see any reason to have a different behavior than yours. What puzzles me now is that I had to rework entry parsing in back-meta to prevent it eating entry controls while parsing attributes, but back-ldap didn't need anything like that... 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

Pierangelo Masarati wrote: > ----- hyc(a)symas.com ha scritto: > >> hyc(a)symas.com wrote: >>> I'll play with this code some with the decode change backed out. >>> >> Heh, in my current build I hadn't updated liblber yet so I didn't have >> the >> change. Fwiw, test036 etc. worked fine without it. Will try some >> syncrepl >> configs now. > > I ran test018, then I put a back-meta between the consumer and the > producer, I wiped the consumer's database and restarted it. Then I performed some further modifications to the producer and checked that they appeared in the consumer. Right, I did the same first with test017. I've now repeated with test018, which works fine since the intermediate message carries the sync cookie. > Please pay attention to the proxy's logs: what you could (should) get is a series of messages complaining about the impossibility to decode attribute types. I didn't see any such errors in the proxy's logs, and the consumer was fine. > I might well have screwed something up while trying to fix intermediate responses and other stuff related to this ITS. That's why I'm asking for critical review before merging my fix into re24. With the change in liblber I could perform syncrepl with back-meta in between. refreshAndPersist seems to work fine without the liblber patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I'll play with this code some with the decode change backed out. >> > Heh, in my current build I hadn't updated liblber yet so I didn't have the > change. Fwiw, test036 etc. worked fine without it. Will try some syncrepl > configs now. > back-meta passes search entry controls fine without the liblber patch. But since back-meta doesn't pass result controls, (ITS#4591) it never propagates the final cookie in refreshonly mode, so the consumer always gets a full refresh every time it reconnects. I'm going to revert the liblber patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

----- hyc(a)symas.com ha scritto: > hyc(a)symas.com wrote: > > I'll play with this code some with the decode change backed out. > > > Heh, in my current build I hadn't updated liblber yet so I didn't have > the > change. Fwiw, test036 etc. worked fine without it. Will try some > syncrepl > configs now. I ran test018, then I put a back-meta between the consumer and the producer, I wiped the consumer's database and restarted it. Then I performed some further modifications to the producer and checked that they appeared in the consumer. Please pay attention to the proxy's logs: what you could (should) get is a series of messages complaining about the impossibility to decode attribute types. I might well have screwed something up while trying to fix intermediate responses and other stuff related to this ITS. That's why I'm asking for critical review before merging my fix into re24. With the change in liblber I could perform syncrepl with back-meta in between. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

hyc(a)symas.com wrote: > I'll play with this code some with the decode change backed out. > Heh, in my current build I hadn't updated liblber yet so I didn't have the change. Fwiw, test036 etc. worked fine without it. Will try some syncrepl configs now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

Pierangelo Masarati wrote: > ----- "Howard Chu"<hyc(a)symas.com> ha scritto: > >> ando(a)sys-net.it wrote: >>> I'm trying to modify the code in order to compute the size of the >>> SearchResultEntry portion of the message, but again, in some cases, >> the >>> size is computed incorrectly: the computed length is 4 octets >> shorter >>> than what's actually in the packet. >>> >>> One issue seems to be related to the fact that when ber_skip_tag() >>> checks if the length it's computed fits in the ber by calling >>> ber_pvt_ber_remaining(), it doesn't count that earlier calls to >>> ber_read() moved the ber_ptr forward. The original ber_ptr should >> be saved. >> >> This sounds wrong; the bytes that ber_read() advanced comprise the >> length >> bytes, but they're not included in the total that the length is >> counting. >> Therefore they should not be accounted for here. > > But without this fix ber_scanf("l") LBER_ERROR was failing because > ber_pvt_ber_remaining(), which is actually ber_end - ber_ptr, is shorter > than *len by the bytes that the ber_reads are advancing. Feel free to back > this out, if you're sure it's incorrect. I'll recheck the syncrepl over > back-meta. Pretty sure. Notice ber_first_element: *last = ber->ber_ptr + *len; All of this has been working for quite a long time... I'll play with this code some with the decode change backed out. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by ando＠sys-net.it 10 Feb '09

10 Feb '09

----- "Howard Chu" <hyc(a)symas.com> ha scritto: > ando(a)sys-net.it wrote: > > I'm trying to modify the code in order to compute the size of the > > SearchResultEntry portion of the message, but again, in some cases, > the > > size is computed incorrectly: the computed length is 4 octets > shorter > > than what's actually in the packet. > > > > One issue seems to be related to the fact that when ber_skip_tag() > > checks if the length it's computed fits in the ber by calling > > ber_pvt_ber_remaining(), it doesn't count that earlier calls to > > ber_read() moved the ber_ptr forward. The original ber_ptr should > be saved. > > This sounds wrong; the bytes that ber_read() advanced comprise the > length > bytes, but they're not included in the total that the length is > counting. > Therefore they should not be accounted for here. But without this fix ber_scanf("l") LBER_ERROR was failing because ber_pvt_ber_remaining(), which is actually ber_end - ber_ptr, is shorter than *len by the bytes that the ber_reads are advancing. Feel free to back this out, if you're sure it's incorrect. I'll recheck the syncrepl over back-meta. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5931) back-meta crashes with syncrepl data
by hyc＠symas.com 10 Feb '09

10 Feb '09

ando(a)sys-net.it wrote: > I'm trying to modify the code in order to compute the size of the > SearchResultEntry portion of the message, but again, in some cases, the > size is computed incorrectly: the computed length is 4 octets shorter > than what's actually in the packet. > > One issue seems to be related to the fact that when ber_skip_tag() > checks if the length it's computed fits in the ber by calling > ber_pvt_ber_remaining(), it doesn't count that earlier calls to > ber_read() moved the ber_ptr forward. The original ber_ptr should be saved. This sounds wrong; the bytes that ber_read() advanced comprise the length bytes, but they're not included in the total that the length is counting. Therefore they should not be accounted for here. > I don't believe messages are encoded incorrectly, so I must be doing > something wrong in decoding them... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5939) Missing close of file descriptor
by hyc＠symas.com 10 Feb '09

10 Feb '09

joakim.bentholm(a)birdstep.com wrote: > Full_Name: Joakim Bentholm > Version: OpenLDAP 2.4.13 > OS: FreeBSD 7.0 Release > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.13.255.38) > > > The running setup: > An ldap server with a socket back-end communicating with server process > listening on incoming requests from the socket back-end and replying in an > orderly fashing. > > The failure: > If the server process shuts down, the socket back-end will continue to try to > connect and allocating new file descriptors which will never be released. If the > server process is restarted everything will work, unless the file descriptor > limit have been reached, in case the ldap server have to be restart. Thanks for the report and patch, fixed now in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs