openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 07 Oct '08

07 Oct '08

Belatead followup: This description of REP_ENTRY_MUSTRELEASE was still wrong. See ITS#5728: BDB didn't set the flag, ITS#3671 just gave the impression it would. Also code much take care to call overlay_entry_release_ov() instead of be_entry_release_r() when appropriate, as in ITS#5451. -- Hallvard

1 0

Re: Bug- Enforcing validation when validator is NULL
by Prashant kulkarni 07 Oct '08

07 Oct '08

Thanks Pierangelo And Harpreet for your reply As you suggested as per latest RFC specification , it is good idea for those attributes who don't have validators or where validator are all NULL to remove those attributes from *.schema files and those syntaxes from hardcoded code files. so any idea in which openLDAP release those attributes will be removed from schema and hardcoded code. ? But currently since these attributes are defined and hard coded in openldap code , the problem is I can't re-define in custom schema exactly with same name as "protocol information" as the openldap service will not start I have to define it as protocol informationXXX or something different to make it work but it then it will breaks the schema for our product which we use for other LDAP server also also I am thinking there is another solution to this bug . in openLDAP code in files /servers/slapd/modify.c and entry.C if all the validator are NULL then it should skip the checking for validation and throwing the error "no validator for syntax". in that way openldap will allow to modify/add values for those attributes having all NULL validator without enforcing. if ( ATLEAST ONE VALIDATOR PRESENT) //pseudo codeIS { if( !pretty && !validate ) { *text = "no validator for syntax"; snprintf( textbuf, textlen, "%s: no validator for syntax %s", ml->sml_type.bv_val, ad->ad_type->sat_syntax->ssyn_oid ); *text = textbuf; return LDAP_INVALID_SYNTAX; } Thanks and Regards Prashant Message: 19 Date: Mon, 29 Sep 2008 20:25:14 +0200 From: Pierangelo Masarati <ando(a)sys-net.it<http://mail.google.com/mail/h/xw1gbla4xfz4/?v=b&cs=wh&to=ando@sys-net.it> > Subject: Re: Bug- Enforcing validation when validator is NULL To: Prashant kulkarni <prashantk100(a)gmail.com<http://mail.google.com/mail/h/xw1gbla4xfz4/?v=b&cs=wh&to=prashantk100@gmail…> > Cc: openldap-bugs(a)openldap.org<http://mail.google.com/mail/h/xw1gbla4xfz4/?v=b&cs=wh&to=openldap-bugs@open…> Message-ID: <48E11D8A.7090706(a)sys-net.it<http://mail.google.com/mail/h/xw1gbla4xfz4/?v=b&cs=wh&to=48E11D8A.7090706@s…> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed Prashant kulkarni wrote: > When I am trying to add/edit the value to the attribute "protocol > information" which is required in our schema I am getting the error > > Invalid syntax :protocol information: no validator for syntax > 1.3.6.1.4.1.1466.115.121.1.42 > > from the earlier mailing list I have found The problem seems to be lack of > validations in the schema_init.c source code for attribure 'Protocol > Information' > > this attribute protocolInformation is defined in core.schema > > {"( 1.3.6.1.4.1.1466.115.121.1.42 DESC 'Protocol Information' )", > 0, NULL, NULL, NULL}, This syntax has been removed from RFC 2252 when revised in RFC 4517, as explicitly indicated in notes 21 and 28 to Appendix B of the latter. This because although mentioned in RFC 2252, those syntaxes were not defined and thus posing interoperability problems. I believe OpenLDAP should move one step forward toward RFC 451* compliance by removing (actually, marking as OBSOLETE) those attributes from *.schema files and those syntaxes from hardcoded ones. > including values like dnPretty ,UTF8StringValidate..etc in the code instead > of NULL values will resolve my problem, but then that require the custom > build and I have to do for all the attributes where validation is defined as > NULL. Not entirely true: you could implement a run-time module that looks up those syntaxes and modifies the appropriate pointers right after initialization. Unless significant changes in the related slapd structures or API, your module would seamlessly breeze through minor and even major releases. Furthermore, if those syntaxes are removed from the hardcoded ones, you could define them via a custom schema file using the X-SUBST feature (ITS#5663) recently introduced in HEAD code. It allows to provide a substitute syntax for unimplemented ones. > I personally feel that for those attributes where validation are NULL in > schema_init.c and other schema files, the openLDAP should not force the > validation and give this error message, as all these attributes in which > validation are not defined becomes unusable . > > In Tivoli/Sun and Microsoft Active directory LDAP validation is not enforced > where validation is defined as NULL hence I am not getting these kind of > error in Tivoli/Sun and Microsoft Active directory for editing of this > attribute . > > So any idea how to resolve this ? there is any way to modify any of the > config file in openldap to disable this validation for protocol information > ? > do I have to raise bug request for the same and is this going to be fixed in > next openLDAP release. ? > > Any help and suggestions in this direction is highly appreciated. I personally believe the absence of a validator for those syntaxes is the safest thing OpenLDAP can do to prevent further interoperability issues. The workaround illustrated above should allow you to circumvent your problem without too much harm. Of course, that's my personal opinion, which might differ from that of the OpenLDAP project. 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<http://mail.google.com/mail/h/xw1gbla4xfz4/?v=b&cs=wh&to=ando@sys-net.it> -----------------------------------

1 0

Re: (ITS#5728) back-bdb should release entries before writing to network
by hyc＠symas.com 06 Oct '08

06 Oct '08

Quanah Gibson-Mount wrote: > --On Monday, October 06, 2008 10:22 PM +0000 hyc(a)OpenLDAP.org wrote: >> back-bdb/hdb should set the REP_ENTRY_MUSTRELEASE flag when calling >> slap_send_search_entry() to prevent this situation. > > This fix breaks back-relay? slapo-rwm was using the wrong entry_release() function... Fixed in HEAD. > > Core was generated by > `/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd -s0 -f > /home/quanah'. > Program terminated with signal 6, Aborted. > #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 > #1 0x00000038dc031980 in abort () from /lib64/libc.so.6 > #2 0x00000038dc029726 in __assert_fail () from /lib64/libc.so.6 > #3 0x0000000000441be3 in entry_clean (e=0x1924ce18) at entry.c:483 > #4 0x0000000000441ccd in entry_free (e=0x1924ce18) at entry.c:514 > #5 0x00000000004458a4 in be_entry_release_rw (op=0x19440d80, e=0x1924ce18, > rw=0) at backend.c:869 > #6 0x00002b0efc860e42 in rwm_send_entry (op=0x19440d80, rs=0x41cf7c80) at > rwm.c:1370 -- -- 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#5728) back-bdb should release entries before writing to network
by quanah＠zimbra.com 06 Oct '08

06 Oct '08

--On Monday, October 06, 2008 10:22 PM +0000 hyc(a)OpenLDAP.org wrote: > back-bdb/hdb should set the REP_ENTRY_MUSTRELEASE flag when calling > slap_send_search_entry() to prevent this situation. This fix breaks back-relay? Core was generated by `/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd -s0 -f /home/quanah'. Program terminated with signal 6, Aborted. #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 #1 0x00000038dc031980 in abort () from /lib64/libc.so.6 #2 0x00000038dc029726 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000441be3 in entry_clean (e=0x1924ce18) at entry.c:483 #4 0x0000000000441ccd in entry_free (e=0x1924ce18) at entry.c:514 #5 0x00000000004458a4 in be_entry_release_rw (op=0x19440d80, e=0x1924ce18, rw=0) at backend.c:869 #6 0x00002b0efc860e42 in rwm_send_entry (op=0x19440d80, rs=0x41cf7c80) at rwm.c:1370 #7 0x00002b0efc8612c9 in rwm_response (op=0x19440d80, rs=0x41cf7c80) at rwm.c:1562 #8 0x00000000004b7751 in over_back_response (op=0x19440d80, rs=0x41cf7c80) at backover.c:235 #9 0x0000000000448aee in slap_response_play (op=0x19440d80, rs=0x41cf7c80) at result.c:307 #10 0x000000000044a6aa in slap_send_search_entry (op=0x19440d80, rs=0x41cf7c80) at result.c:792 #11 0x00002b0efbdb8a9f in bdb_search (op=0x19440d80, rs=0x41cf7c80) at search.c:927 #12 0x00002b0efbfed03c in relay_back_op (op=0x19440d80, rs=0x41cf7c80, bd=0x191ce440, func=0x2b0efbdb6ab6 <bdb_search>, fail_mode=2952790069) at op.c:148 #13 0x00002b0efbfed216 in relay_back_op_search (op=0x19440d80, rs=0x41cf7c80) at op.c:218 #14 0x00000000004b8666 in overlay_op_walk (op=0x19440d80, rs=0x41cf7c80, which=op_search, oi=0x191d0100, on=0x0) at backover.c:667 #15 0x00000000004b8869 in over_op_func (op=0x19440d80, rs=0x41cf7c80, which=op_search) at backover.c:719 #16 0x00000000004b88ff in over_op_search (op=0x19440d80, rs=0x41cf7c80) at backover.c:741 #17 0x0000000000437568 in fe_op_search (op=0x19440d80, rs=0x41cf7c80) at search.c:366 #18 0x0000000000436ea7 in do_search (op=0x19440d80, rs=0x41cf7c80) at search.c:217 #19 0x0000000000433c6b in connection_operation (ctx=0x41cf7dd0, arg_v=0x19440d80) at connection.c:1084 #20 0x0000000000434186 in connection_read_thread (ctx=0x41cf7dd0, argv=0xc) at connection.c:1210 #21 0x00002b0ef9dcb9d7 in ldap_int_thread_pool_wrapper (xpool=0x19172610) at tpool.c:663 #22 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #23 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #24 0x0000000000000000 in ?? () --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5728) back-bdb should release entries before writing to network
by hyc＠OpenLDAP.org 06 Oct '08

06 Oct '08

Full_Name: Howard Chu Version: 2.3/2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Currently we provide SlapReply flag REP_ENTRY_MUSTRELEASE which tells slap_send_search_entry() to release the current entry before writing to the network. syncprov uses it, but not much else does. If a client issues a search request that produces a large result set, and the client doesn't read the results quickly enough, eventually the socket buffers on client and server will fill up, and the slapd thread writing to the connection will block. If it blocks while writing an entry that is still readlocked, then attempts to modify that entry will hang. Subsequent attempts to read that entry will also hang after a write has hung. back-bdb/hdb should set the REP_ENTRY_MUSTRELEASE flag when calling slap_send_search_entry() to prevent this situation.

1 0

Re: (ITS#5526) Another segmentation fault
by h.b.furuseth＠usit.uio.no 06 Oct '08

06 Oct '08

This fix introduced some garbage in debugging output. It's cleaned up in cvs HEAD and the upcoming OpenLDAP 2.4.12. -- Regards, Hallvard

1 0

ITS#5727
by ando＠sys-net.it 06 Oct '08

06 Oct '08

[reposted; wrong sender] Cannot reproduce: a SIZELIMIT of 0 in ldaprc results in sending 0 on the wire, which causes the server to ignore it (and apply server-side limitations, eventually). HEAD, same with re24. Please check what file the sizelimit is actually read from by the client; also, check what size limit is actually received and subsequently enforced by the server. 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

ITS#5727
by masarati＠aero.polimi.it 06 Oct '08

06 Oct '08

Cannot reproduce: a SIZELIMIT of 0 in ldaprc results in sending 0 on the wire, which causes the server to ignore it (and apply server-side limitations, eventually). HEAD, same with re24. Please check what file the sizelimit is actually read from by the client; also, check what size limit is actually received and subsequently enforced by the server. p.

1 0

Re: ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
by ando＠sys-net.it 06 Oct '08

06 Oct '08

ando(a)sys-net.it wrote: > Sharing the pointer to the supported controls would allow to use the > actual set. Something along the line > > struct BackendDB { > char be_ctrlsbuf[SLAP_MAX_CIDS + 1]; > char *be_ctrls; > }; > > All backends would have be_ctrls = be_ctrlsbuf, but back-relay would set > it to NULL, and temporarily set it to the relayed database's be_ctrlsbuf > for the duration of an operation. Modules wouldn't be able to register > new controls because the pointer is null otherwise. Of course, this wouldn't work since it implies modifying the BackendDB structure, which is read-only :( 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

(ITS#5727) SIZELIMIT 0 gives a zero limit
by fabio.pedretti＠ing.unibs.it 06 Oct '08

06 Oct '08

Full_Name: Fabio Pedretti Version: 2.4.11 OS: Slackware 10.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.167.17.10) The ldap.conf man page says this: SIZELIMIT <integer> Specifies a size limit to use when performing searches. The number should be a non-negative integer. SIZELIMIT of zero (0) specifies unlimited search size. However it appears that putting "SIZELIMIT 0" in my ldap.conf gives a: # search result search: 2 result: 4 Size limit exceeded To workaround this I put a very large value and it works. I am using openldap 2.4.11 compiled from source on a Slackware 10.0. Is it an openldap bug? Thanks, Fabio

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