- openldap-bugs - openldap.org

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by hyc＠symas.com 02 Apr '07

02 Apr '07

unix.gurus(a)gmail.com wrote: > Full_Name: Sean Burford > Version: 2.3.32 > OS: Linux 2.4.20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.57.245.11) > > > I am attempting to set up syncrepl between two OpenLDAP 2.3.32 servers. Adds > and Modifies are replicated from the provider to the consumer, but deletes > result in thousands of "unknown filter type 136644788" messages in the consumer > log and no deletion. Commenting out the syncprov-sessionlog directive works > around the issue. I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to trace the activity with gdb to see what's wrong with the filter. -- -- Howard Chu Chief Architect, 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#4879) URL parse/unparse troubles
by hyc＠symas.com 02 Apr '07

02 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > Here are some URLs parsing/building bugs in libldap/url.c. > Some may be design bugs. Possibly some fixes will need backwards > bug-compatibility. > > I show URLs converted from string to LDAPURLDesc format with > ldap_url_parse(), back to string format with ldap_url_desc2str() > when the result differs from the original, back to LDAPURLDesc... > > ================ > > The url.c Novell kludge does not work (for the example URL). > If the bug is old and nobody has complained, maybe it should be > removed. If it's fixed instead, note that the code looks like > it'll handle Novell URLs with '/' in components after hostport: > ldap_url_parse_ext() does strchr( url, '/' ) very early to find > the end of the hostport. Hm, I think I see what you mean, but I don't see what to do about that. > ldap://111.222.333.444:389??cn=abc,o=company -> > error 5 (LDAP_URL_ERR_BADURL) This now works. > > Example URL without port number: > > ldap://111.222.333.444??cn=abc,o=company -> > host "111.222.333.444??cn=abc,o=company", DN NULL -> > ldap://111.222.333.444??cn=abc,o=company:389/??base This now works. > > ================ > > ldap_url_desc2str() outputs IPv6 host addresses as "addr" rather > than "[addr]". (LDAPURLDesc does not contain the '[]'s in > .lud_host, nor any flag which says it's an IPv6 host address). > > I don't know the syntax of such addresses, but I seem to remember > they contains ':'s. If so the parser could fail if an IPv6 > address does not contains ':', and the URL builder could test for > ':' to determine if there should be [] around the host part. This now works. > > Also, what does stuff between the ']' and ':port' mean? > Should anything be allowed there? > > ldap://[::1]what's this:222/ -> host "::1", port 222 -> This is now correctly rejected. > ldap://::1:222/??base -> error 5 (LDAP_URL_ERR_BADURL) > > ================ > > Converting "%00" to char* should return an error, since the char* > will not match the source URL: > > ldapi://a%00b/cn=d%00e -> host "a", DN "cn=d" -> > ldapi://a/cn=d??base I've left this alone for now. > ================ > > The RFCs 4516/2255 hostport part has grammar [host [":" port]], > but ldap_url_desc2str() produces [host][":" port]. > > ldap:// -> host NULL, port 389 -> > ldap://:389/??base > > That's OK as an ldap_url_parse() OpenLDAP extension, but not as > ldap_url_desc2str() output given to non-OpenLDAP applications. This is a mess. The ldap: scheme definition has always been broken, and it certainly does not conform to the basic URI syntax in RFC3986 section 3. In particular, RFC3986 forbids a URI from containing "//" when the authority component is absent. Looks like RFC4516 should not have been approved in its current state. > ================ > > While I'm writing, I wonder if OpenLDAP 2.4 could omit defaults > and final "?"s from the ldap_url_desc2str() output. E.g. ldap:// > would become ldap:// and not ldap://:389/??base. But maybe we get > into trouble if ldap.conf has another port or something. I thought about changing this, but left it alone for now. Agreed, the interaction with ldap.conf isn't clear. > ================ > > ldapi URL (un)parsing has several problems: > > ldap_url_parse() always treats ':' as a host:port separator. > Thus one can produce an ldapi LDAPURLDesc with a meaningless port. > However ldap_url_desc2str() does not URL-escape ':', and it also > takes port!=0 to mean it is not an ldapi URL and needs no > '/'-escaping. Similarly filenames with initial '[' do not work. > > ldapi://%2Ftmp%2Ffoo%3A222/ -> host "/tmp/foo:222" (correct) -> > ldapi://%2Ftmp%2Ffoo:222/??base -> host "/tmp/foo", port 222 -> > ldapi:///tmp/foo:222/??base -> host NULL, DN "tmp/foo:222/" > > ldapi://%2Ftmp%2Ffoo:000/ -> host "/tmp/foo" -> > ldapi://%2Ftmp%2Ffoo/??base > > ldapi://%2Ftmp%2Ffoo:bar/ -> error 5 (LDAP_URL_ERR_BADURL) These are all fixed. Note that the "ldapi:///tmp/foo:222/" case simply means an ldapi:// URL with a DN of "tmp/foo:222/" which is legal in a URL parsing sense, even though DN validation would reject it. > > ==== > > The current implementation would handle some non-Unix ldapi > filenames wrong. (They'll need well-defined URL-escaping rules > if they get implemented, so it might as well be fixed now.) Of > course these can also be strange Unix relative filenames... > > Windows-like filenames: > > ldapi://C%3A%2Fldapi/ -> host "C:/ldapi" -> > ldapi://C:%2Fldapi/??base -> error 5 (LDAP_URL_ERR_BADURL) > > Tops-20-like filenames resemble IPv6 addresses (not that I expect > to port OpenLDAP to Tops-20:-) > > ldapi://[ldap.var.run]ldapi/ -> host "ldap.var.run" -> > ldapi://ldap.var.run/??base > > URL-escaping the '[' and ']' does not help; the '[' is lost: > > ldapi://%5Bldap.var.run%5Dldapi/ -> host "ldap.var.run]ldapi" -> > ldapi://ldap.var.run%5Dldapi/??base > These are all fixed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4907) Syncrepl consumer failing to perform deletes
by unix.gurus＠gmail.com 02 Apr '07

02 Apr '07

Full_Name: Sean Burford Version: 2.3.32 OS: Linux 2.4.20 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.57.245.11) I am attempting to set up syncrepl between two OpenLDAP 2.3.32 servers. Adds and Modifies are replicated from the provider to the consumer, but deletes result in thousands of "unknown filter type 136644788" messages in the consumer log and no deletion. Commenting out the syncprov-sessionlog directive works around the issue. The search that the syncrepl consumer does, when presented with a delete from the syncprov log, seems to be poorly formed or corrupted. Overflowing the syncprov-sessionlog between consumer polls prevents this behaviour. Provider config: overlay syncprov syncprov-checkpoint 100 10 # Values 1 and 100 tested for syncprov-sessionlog. # Both have same symptoms. syncprov-sessionlog 1 Consumer config: syncrepl rid=007 provider=ldaps://ldaptest-master.SITE:636 type=refreshOnly interval=00:00:00:10 searchbase="XXX" filter="(objectClass=*)" scope=sub # Different attrs values do not affect this issue attrs="*,+" schemachecking=off # Different bind methods do not affect this issue bindmethod=sasl saslmech=GSSAPI updateref ldap://ldaptest-master.SITE:389 With "loglevel stats sync" on the consumer, syslog logs this: Apr 2 13:18:16 slapd[964]: do_syncrep2: rid 007 LDAP_RES_SEARCH_RESULT Apr 2 13:18:26 slapd[964]: do_syncrep2: rid 007 LDAP_RES_SEARCH_RESULT Apr 2 13:18:36 slapd[964]: do_syncrep2: rid 007 LDAP_RES_SEARCH_RESULT Apr 2 13:18:46 slapd[964]: do_syncrep2: rid 007 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 2 13:18:46 slapd[964]: unknown filter type 136644788 Apr 2 13:18:46 slapd[964]: unknown filter type 136644788 Apr 2 13:18:46 slapd[964]: unknown filter type 136644788 Apr 2 13:18:46 slapd[964]: unknown filter type 136644788 ... Running slapd with -d1 on the consumer produces the following debug output. You can see the intermediate result getting parsed (it contains the refreshdeletes flag then a set of (one) UUIDs to delete). The backend is then searched for the UUID, but each entry in the backend generates an unknown filter type message: ... read1msg: ld 0x8814ea0 msgid 2 message type intermediate ber_scanf fmt ({eaa) ber: ldap_parse_intermediate ber_scanf fmt ({) ber: ber_scanf fmt (a) ber: ber_scanf fmt (O) ber: ber_scanf fmt (t{) ber: ber_scanf fmt (m) ber: ber_scanf fmt (b) ber: ber_scanf fmt ([W]) ber: ber_scanf fmt (}) ber: => bdb_search bdb_dn2entry("dc=XXX") search_candidates: base="dc=XXX" (0x00000001) scope=2 => bdb_dn2idl("dc=XXX") bdb_search_candidates: id=-1 first=1 last=203912 unknown filter type 136644788 bdb_search: 1 does not match filter entry_decode: "ou=YYY,XXX" <= entry_decode(ou=YYY,XXX) => bdb_dn2id("ou=YYY,XXX") <= bdb_dn2id: got id=0x00000002 unknown filter type 136644788 bdb_search: 2 does not match filter ... entry_decode: "uid=ZZZ,YYY" <= entry_decode(uid=ZZZ,YYY) unknown filter type 136644788 bdb_search: 203912 does not match filter send_ldap_result: conn=-1 op=0 p=3 ldap_msgfree ldap_result ld 0x8814ea0 msgid -1 ldap_chkResponseList ld 0x8814ea0 msgid -1 all 0 ldap_chkResponseList returns ld 0x8814ea0 NULL wait4msg ld 0x8814ea0 msgid -1 (infinite timeout) wait4msg continue ld 0x8814ea0 msgid -1 all 0 136644788 (0x82508B4) is not consistent across runs, it appears to be an address in the JCR rather than a valid filter type. The delete message content looks OK: 0040 30 68 02 01 02 79 63 80 18 31 2e 33 2e 36 0h...y c..1.3.6 | | | | +---------------syncoid.syncinfo | | | +---------------------req oid (len 0x18) | | +-----------------------length 0x63 | +---------------------------result intermediate +-------------------------------------message ID 2 0050 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 39 2e .1.4.1.4 203.1.9. 0060 31 2e 34 81 47 a3 45 04 2c 63 73 6e 3d 32 30 30 1.4.G.E. ,csn=200 | | | +---------------------CSN,RID (cookie) | | +----------------------------sync cookie (len 0x2c) | +----------------------------------SYNC_ID_SET (len 0x45) +----------------------------------------req value (len 0x47) 0070 37 30 34 30 32 32 30 34 38 32 33 5a 23 30 30 30 70402204 823Z#000 0080 30 30 30 23 30 30 23 30 30 30 30 30 30 2c 72 69 000#00#0 00000,ri 0090 64 3d 30 30 37 01 01 ff 31 12 04 10 48 4a 1b 88 d=007... 1...HJ.. | | | +------------UUID (remainder of packet) | | +------------------octetstring (len 0x10) | +------------------------lber set (len 0x12) +----------------------------------refreshdeletes(bool:FF) 00a0 75 a6 10 2b 8c 79 83 6d 14 6d 34 77 Backend: bdb 4.4.20

1 0

Re: (ITS#4881) ldapsearch, SSL and segmentation fault
by hyc＠symas.com 02 Apr '07

02 Apr '07

andrej.groups(a)gmail.com wrote: > Full_Name: Andrej Ricnik > Version: ldapsearch 2.3.21 > OS: Slackware 11 > URL: > Submission from: (NULL) (138.235.105.2) > > > I'm trying to use ldapsearch against Novell eDir 8.7.3.9 (on Solaris) which > works fine when used w/o encryption. If I use the self-signed Cert created on > the eDir server ldapsearch segfaults. > > This works fine (returns the expected 46 DNs): > ldapsearch -D cn=wpsbind,ou=wcm,ou=systemusers,ou=users,o=myorg -W -h > dev4.kdc.myorg.org -x -s sub -LLL '(cn=*)' > > This one segfaults after the 45th DN: > ldapsearch -ZZ -D cn=wpsbind,ou=wcm,ou=systemusers,ou=users,o=myorg -W -h > dev4.kdc.myorg.org -x -s sub -LLL '(cn=*)' > > It looks similar to ITN# 889 ... Not likely, since that involved SASL and this does not. There's not enough info here. Please provide a stack trace of the crash in the client. Also see the FAQ http://www.openldap.org/faq/index.cgi?file=59 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by hyc＠symas.com 02 Apr '07

02 Apr '07

imriz(a)co.zahav.net.il wrote: > Sure. New core dumps and binary file is at > http://mariska.inter.net.il/~imriz/slapd-core.tar.gz The slapd in this snapshot was stripped so no debug symbols are present. Please be sure to use an unstripped binary. Also, since you're also loading libldap_r, liblber, back-ldap, back-bdb, back-meta, and back-ldbm dynamically, you'll need to include those modules in the tarball. (Also with debug and unstripped.) Although at this point I'm wondering why you're using back-ldbm, which has been deprecated for quite a long time. > Please notice that the previous dump was from FreeBSD ports (OpenLDAP > version 2.3.33). > > This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the > following configure options: > > ./configure --with-threads=posix --with-tls=openssl --enable-dynamic > --without-cyrus-sasl --enable-modules --localstatedir=/var/ > db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable-ldap=mod > --enable-meta=mod --enable-rewrite --enable-null=mod --enabl > e-monitor=mod --enable-proxycache --disable-syncprov --enable-bdb=mod > --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd -- > prefix=/usr/local --enable-debug > > > -----Original Message----- > From: Howard Chu [mailto:openldap-its@OpenLDAP.org] > Sent: Tuesday, February 13, 2007 1:14 AM > To: Imri Zvik > Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > > It looks like this core is from a binary without debug symbols present, > can you > recompile with debugging enabled and get a new stack trace and core > file? > > > . > -- -- Howard Chu Chief Architect, 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#4903) dynlist issues with memory allocation
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--On Monday, April 02, 2007 7:44 PM +0000 quanah(a)stanford.edu wrote: > > > --On Monday, April 02, 2007 9:42 PM +0200 Pierangelo Masarati > <ando(a)sys-net.it> wrote: > >> quanah(a)stanford.edu wrote: >> >>> database hdb >>> suffix "dc=stanford,dc=edu" >>> rootdn "cn=manager,dc=stanford,dc=edu" >>> >>> overlay valsort >>> valsort-attr suOrgContactStanford cn=orgs,dc=stanford,dc=edu weighted >>> valsort-attr suOrgContactWorld cn=orgs,dc=stanford,dc=edu weighted >>> >>> overlay dynlist >>> dynlist-attrset groupOfURLS memberURL member >>> >>> limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" >>> time.soft=unlimited time.hard=unlimited size.soft=unlimited >>> size.hard=unlimited >> >> There it is: "limits" is a database specific directive appearing >> __after__ overlay instantiation. Try moving all database-specific >> directives __before__ any overlay instantiation. > > Ah, I see... So its not just global/db. > > So all overlay bits should be listed last? And I assume this only > happens when you have more than one overlay in use? Because it only > happens once both valsort and dynlist are enabled. In any case, reordering the slapd.conf files so the overlay stuff all appears last has definitely fixed it. Yeah, and thanks. :) There's a lot I'm looking forward to in 2.4. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4903) dynlist issues with memory allocation
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--On Monday, April 02, 2007 12:42 PM -0700 Quanah Gibson-Mount <quanah(a)stanford.edu> wrote: > Ah, I see... So its not just global/db. > > So all overlay bits should be listed last? And I assume this only > happens when you have more than one overlay in use? Because it only > happens once both valsort and dynlist are enabled. That doesn't seem to be it either. For example, on my master, I have: database hdb suffix "dc=stanford,dc=edu" rootdn "cn=manager,dc=stanford,dc=edu" # Syncrepl Provider overlay syncprov syncprov-checkpoint 1000 60 # Dynamic Group Overlay overlay dyngroup # Uniqueness Overlay overlay unique unique_base cn=people,dc=stanford,dc=edu unique_attributes suunivid suproxycardnumber sucardnumber suuniqueidentifier # Valsort Overlay overlay valsort valsort-attr suOrgContactStanford cn=orgs,dc=stanford,dc=edu weighted valsort-attr suOrgContactWorld cn=orgs,dc=stanford,dc=edu weighted #valsort-attr ou cn=people,dc=stanford,dc=edu weighted #valsort-attr suAffiliation cn=people,dc=stanford,dc=edu weighted #valsort-attr suDisplayAffiliation cn=people,dc=stanford,dc=edu weighted overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 # Let ldapadmin have limitless searches limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits group="cn=ldapreplica,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # Save the time that the entry gets modified lastmod on # Set the location of where the database storage files go. directory /var/lib/ldap dbconfig set_cachesize 3 536870912 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_lg_dir /var/log/bdb dbconfig set_lk_max_locks 3000 # # Automatically remove log files that are no longer needed. dbconfig set_flags DB_LOG_AUTOREMOVE # # Setting set_tas_spins reduces resource contention from multiple clients on systems with multiple CPU's. dbconfig set_tas_spins 1 # Checkpoint the database to prevent transaction loss in unclean shutdowns, and speed up slapd shutdowns. checkpoint 1024 5 # Indices to maintain index default eq index cn index dc index entryCSN index entryUUID index objectClass index krb5PrincipalName index suCardNumber index suGeneralID index suProxyCardNumber index suRegID index suUniqueIdentifier index suUnivID index uid ####################################################################### # back-monitor database definitions ####################################################################### database monitor As you can see, *multiple* overlay statements and directives, prior to the "limits" command. It does not exhibit the problems I see on my replica. The issue only arises once dynlist is enabled. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4903) dynlist issues with memory allocation
by ando＠sys-net.it 02 Apr '07

02 Apr '07

Quanah Gibson-Mount wrote: > Ah, I see... So its not just global/db. > > So all overlay bits should be listed last? And I assume this only > happens when you have more than one overlay in use? Because it only > happens once both valsort and dynlist are enabled. Well, the issue is subtle. You risk inconsistency whenever an overlay supports back-config __and__ the out-of-order directive uses some special back-config feature, like the possibility to directly write a value to the database/overlay structure. The way back-config statement/data structure resolution is designed in re23, the out-of-order directive will use the wrong data structure, thus resulting at least in breaking the configuration but, in some cases, in breaking the consistency of the process, by randomly writing, for example, on the stack or on the heap. This should be now fixed in HEAD, but the fix was not so easy to backport because back-config significantly changed in the meanwhile. So, since usually there is no need to write out-of-order statements (back-meta could be an exception, but fortunately enough it doesn't support back-config yet :), there is no pressure for fixing this issue in re23. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 ------------------------------------------

1 0

Re: (ITS#4903) dynlist issues with memory allocation
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--On Monday, April 02, 2007 9:42 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: > quanah(a)stanford.edu wrote: > >> database hdb >> suffix "dc=stanford,dc=edu" >> rootdn "cn=manager,dc=stanford,dc=edu" >> >> overlay valsort >> valsort-attr suOrgContactStanford cn=orgs,dc=stanford,dc=edu weighted >> valsort-attr suOrgContactWorld cn=orgs,dc=stanford,dc=edu weighted >> >> overlay dynlist >> dynlist-attrset groupOfURLS memberURL member >> >> limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" >> time.soft=unlimited time.hard=unlimited size.soft=unlimited >> size.hard=unlimited > > There it is: "limits" is a database specific directive appearing > __after__ overlay instantiation. Try moving all database-specific > directives __before__ any overlay instantiation. Ah, I see... So its not just global/db. So all overlay bits should be listed last? And I assume this only happens when you have more than one overlay in use? Because it only happens once both valsort and dynlist are enabled. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4903) dynlist issues with memory allocation
by ando＠sys-net.it 02 Apr '07

02 Apr '07

quanah(a)stanford.edu wrote: > database hdb > suffix "dc=stanford,dc=edu" > rootdn "cn=manager,dc=stanford,dc=edu" > > overlay valsort > valsort-attr suOrgContactStanford cn=orgs,dc=stanford,dc=edu weighted > valsort-attr suOrgContactWorld cn=orgs,dc=stanford,dc=edu weighted > > overlay dynlist > dynlist-attrset groupOfURLS memberURL member > > limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" > time.soft=unlimited time.hard=unlimited size.soft=unlimited > size.hard=unlimited There it is: "limits" is a database specific directive appearing __after__ overlay instantiation. Try moving all database-specific directives __before__ any overlay instantiation. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 ------------------------------------------

1 0

Re: (ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by ando＠sys-net.it 02 Apr '07

02 Apr '07

Please keep replies on the ITS: the "T" stands for "tracking". Wei Weng wrote: > I just installed 2.3.34 version that was found to be the latest > "Release" from openLDAP. Not only there isn't any mention of > LDAP_DEPRECATED, in OpenLDAP 2.3 source tree: bash-3.00$ grep LDAP_DEPRECATED -rI include/ include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED include/ldap.h:#if LDAP_DEPRECATED > but there isn't manpage for the new ldap_initialize > function either. You're right, it's only been released starting with 2.4. > I am just very surprised that a quite mature openLDAP open source > projects can be this careless about the documentation. I already explained the reason in my previous posting. It's not lack of care, it's optimization of resources. The code works fine also without documentation, which eventually will converge (and it __is__ converging, in OpenLDAP 2.4). > There is (only > place) mention of ldap_initialize function in ldap.3: "A session handle > is created using ldap_initialize(3)". Naturally you want to do a man > ldap_initialize but there is nothing. ITS#3947 addresses this issue. > I was reporting this bug so that the "newbies" (new to openLDAP APIs) > won't be stuck like I was for a few hours. Then you probably should have entitled your posting "some C API man pages seem to be missing from OpenLDAP 2.3 code", or even better "this is a duplicate of ITS#2240". > Isn't the "Documentation" > supposed to help you to understand the APIs? This is not a bug. This is missing documentation, which is different. It is a known issue (ITS#2240), so your post is only adding noise. A non-noisy posting would have been accompanied by a patch fixing the issue, which is however already fixed in re24 (that's why ITS#2240 is now closed). > By the way, if you guys ask me to supply patch for the ldap_initialize, > sorry, I was just maintaining the old code to try to compile it on a > Fedora 5 box. The details about ldap APIs is above my ability. > > PS: ldap_initialize is just an example, there are also a bunch of other > functions that seemed to have been deprecated. Please check OpenLDAP 2.4. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 ------------------------------------------

1 0

Re: (ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--On Monday, April 02, 2007 10:59 AM -0700 Quanah Gibson-Mount <quanah(a)stanford.edu> wrote: > > I.e., ldap_init is a deprecated function, and ldap_initialize should be > used instead. However, there are many programs out there that still use > the old API, so the old functions are maintained for backwards > compatibility purposes. Hence the man page. I will also note that ldap_initialize has a man page in the 2.4 release: <http://www.openldap.org/software/man.cgi?query=ldap_initialize&apropos=0&se…> --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4903) dynlist issues with memory allocation
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--On Monday, April 02, 2007 9:09 PM +0200 Pierangelo Masarati <ando(a)sys-net.it> wrote: >> It looks like there's soemthing incorrect in the way it is allocating >> memory on startup. > > Apparently, there's nothing directly related to dynlist; can you post > the entire slapd.conf? I suspect something like ITS#4848, which is NOT > fixed in re23 (and likely won't). I've looked at the ITS, and I don't think it is related. As far as I know, everything in it is specifically located where it should be (global bits in the global area, database specific bits in the database areas): My slapd.conf is: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/krb5-kdc.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/eduperson.schema include /usr/local/etc/openldap/schema/stanford-oids.schema include /usr/local/etc/openldap/schema/suacct.schema include /usr/local/etc/openldap/schema/superson.schema include /usr/local/etc/openldap/schema/suapplication.schema include /usr/local/etc/openldap/schema/suorg.schema include /usr/local/etc/openldap/schema/eduorg.schema include /usr/local/etc/openldap/schema/suworkgroup.schema allow bind_v2 TLSCertificateFile /usr/local/etc/openldap/stardomain.crt TLSCertificateKeyFile /usr/local/etc/openldap/stardomain.key TLSCACertificateFile /usr/local/etc/openldap/comodo.pem include /usr/local/etc/openldap/slapd.acl pidfile /var/run/slapd.pid argsfile /var/run/slapd.args defaultsearchbase "dc=stanford,dc=edu" gentlehup off loglevel 256 threads 8 tool-threads 2 sasl-realm stanford.edu sasl-authz-policy both sasl-regexp uid=(.*)/cgi,cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=cgi,cn=applications,dc=stanford,dc=edu??sub?krb5PrincipalName=$1/cgi@stanford.edu sasl-regexp uid=service/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Service,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=service/$1@stanford.edu sasl-regexp uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Webauth,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=webauth/$1@stanford.edu sasl-regexp uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///uid=$1,cn=Accounts,dc=stanford,dc=edu??sub?suSeasStatus=active reverse-lookup on modulepath /usr/local/lib/openldap moduleload back_hdb.la moduleload back_monitor.la moduleload valsort.la moduleload dynlist.la database hdb suffix "dc=stanford,dc=edu" rootdn "cn=manager,dc=stanford,dc=edu" overlay valsort valsort-attr suOrgContactStanford cn=orgs,dc=stanford,dc=edu weighted valsort-attr suOrgContactWorld cn=orgs,dc=stanford,dc=edu weighted overlay dynlist dynlist-attrset groupOfURLS memberURL member limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=athletics,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=workgroup-audit,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=RegistryDataAuditor,cn=Service,cn=Applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited limits dn.exact="cn=ispace,cn=Service,cn=Applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=5000 size.hard=5000 limits dn.exact="cn=gsb-person,cn=service,cn=applications,dc=stanford,dc=edu" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited lastmod on syncrepl rid=0 provider=ldap://ldap-devmaster.stanford.edu:389 bindmethod=sasl saslmech=gssapi realm=stanford.edu searchbase="dc=stanford,dc=edu" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog # Replica Directives updateref ldap://ldap-devmaster.stanford.edu directory /var/lib/ldap dbconfig set_cachesize 3 536870912 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_lg_dir /var/log/bdb dbconfig set_lk_max_locks 3000 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_lockers 1500 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_tas_spins 1 checkpoint 1024 5 cachesize 50000 idlcachesize 50000 cachefree 1000 index_substr_any_len 3 index default eq (Long list of indices) database monitor -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4904) delta-sync can free modlist redundantly
by hyc＠OpenLDAP.org 02 Apr '07

02 Apr '07

Full_Name: Howard Chu Version: 2.3/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc In syncrepl_message_to_op the modlist is copied to op->orm_modlist and then freed after op->o_bd->be_modify. But the modify can alter the modlist (e.g., ppolicy overlay) causing a redundant free later on.

1 0

Re: (ITS#4903) dynlist issues with memory allocation
by ando＠sys-net.it 02 Apr '07

02 Apr '07

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: RE_23 > OS: Linux 2.6 (64-bit) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > > > In testing the RE_23 tree, I put it under hoard after everything passed using > glibc as the memory allocator. I found that if I enable dynlist: > > moduleload dynlist.la > > then in my database section add: > > # Dynlist Overlay > overlay dynlist > dynlist-attrset groupOfURLS memberURL member > > > slapd will core dump on startup with: > > Loaded symbols for /usr/local/lib/openldap/dynlist-2.3-releng.so.0 > #0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so > (gdb) bt > #0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so > #1 0x00002ab765149e38 in realloc () from /usr/local/lib/libhoard.so > #2 0x00002ab76554f890 in ber_memrealloc_x (p=Variable "p" is not available. > ) at memory.c:354 > #3 0x00002ab76542bf88 in ldap_charray_add (a=0x7fff45a7eec0, s=0x2ab7667c2518 > "olcConnMaxPending") at charray.c:49 > #4 0x000000000045e9f9 in matching_rule_use_init () at mr.c:364 > #5 0x0000000000459f62 in slap_schema_check () at schema_prep.c:1368 > #6 0x0000000000415f1b in main (argc=3, argv=0x7fff45a7f0b8) at main.c:711 > > > It looks like there's soemthing incorrect in the way it is allocating memory on > startup. Apparently, there's nothing directly related to dynlist; can you post the entire slapd.conf? I suspect something like ITS#4848, which is NOT fixed in re23 (and likely won't). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 ------------------------------------------

1 0

(ITS#4903) dynlist issues with memory allocation
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

Full_Name: Quanah Gibson-Mount Version: RE_23 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In testing the RE_23 tree, I put it under hoard after everything passed using glibc as the memory allocator. I found that if I enable dynlist: moduleload dynlist.la then in my database section add: # Dynlist Overlay overlay dynlist dynlist-attrset groupOfURLS memberURL member slapd will core dump on startup with: Loaded symbols for /usr/local/lib/openldap/dynlist-2.3-releng.so.0 #0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so (gdb) bt #0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so #1 0x00002ab765149e38 in realloc () from /usr/local/lib/libhoard.so #2 0x00002ab76554f890 in ber_memrealloc_x (p=Variable "p" is not available. ) at memory.c:354 #3 0x00002ab76542bf88 in ldap_charray_add (a=0x7fff45a7eec0, s=0x2ab7667c2518 "olcConnMaxPending") at charray.c:49 #4 0x000000000045e9f9 in matching_rule_use_init () at mr.c:364 #5 0x0000000000459f62 in slap_schema_check () at schema_prep.c:1368 #6 0x0000000000415f1b in main (argc=3, argv=0x7fff45a7f0b8) at main.c:711 It looks like there's soemthing incorrect in the way it is allocating memory on startup. --Quanah

1 0

Re: (ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by ando＠sys-net.it 02 Apr '07

02 Apr '07

quanah(a)stanford.edu wrote: >> I don't know if the people who are in charge to build a RPM are paying >> attention to what they are doing or not. >> >> You can do a man ldap_init, and then look at /usr/include/ldap.h for the >> function definition. >> >> I am not a LDAP expert or anything close to that. But it seems to me that >> function called ldap_init has already been replaced by the function called >> ldap_initialize, and they take even different set of parameters. >> >> And yet the manpage not only didn't reflect that change, but enforce the >> wrong idea of using ldap_init function by having ldap_init in manpages. >> >> An extremely poor job done by the package maintainer. > > Hi, > > I suggest you complain to RedHat if you don't like the way they've packaged > something. The OpenLDAP foundation is not responsible for the way in which > RedHat packages its releases. In any case, if you are taking the time to > read the header file, then pay close attention to the following: > > #if LDAP_DEPRECATED > LDAP_F( LDAP * ) > ldap_init LDAP_P(( /* deprecated, use ldap_create or ldap_initialize */ > LDAP_CONST char *host, > int port )); > > > I.e., ldap_init is a deprecated function, and ldap_initialize should be > used instead. However, there are many programs out there that still use > the old API, so the old functions are maintained for backwards > compatibility purposes. Hence the man page. I'd add that OpenLDAP is a voluntary based project, and volunteers devote their efforts to what they consider mostly important - typically writing good useful code that runs (fast). Man pages typically lag behind, but eventually they get updated/fixed (as they are in currently released code). If you cared so much about up-to-date code and man pages, you would be using the latest release, not a 15 months old one. And if you were able to infer the really useful API from ldap.h, you could have more proficiently spent your time by writing and submitting a useful man page, instead of just complaining quite unpolitely. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 ------------------------------------------

1 0

Re: (ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--On Monday, April 02, 2007 5:23 PM +0000 wweng(a)kencast.com wrote: > Full_Name: Wei Weng > Version: 2.3.19 > OS: Linux(Fedora 5) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.120.101.108) > > > I don't know if the people who are in charge to build a RPM are paying > attention to what they are doing or not. > > You can do a man ldap_init, and then look at /usr/include/ldap.h for the > function definition. > > I am not a LDAP expert or anything close to that. But it seems to me that > function called ldap_init has already been replaced by the function called > ldap_initialize, and they take even different set of parameters. > > And yet the manpage not only didn't reflect that change, but enforce the > wrong idea of using ldap_init function by having ldap_init in manpages. > > An extremely poor job done by the package maintainer. Hi, I suggest you complain to RedHat if you don't like the way they've packaged something. The OpenLDAP foundation is not responsible for the way in which RedHat packages its releases. In any case, if you are taking the time to read the header file, then pay close attention to the following: #if LDAP_DEPRECATED LDAP_F( LDAP * ) ldap_init LDAP_P(( /* deprecated, use ldap_create or ldap_initialize */ LDAP_CONST char *host, int port )); I.e., ldap_init is a deprecated function, and ldap_initialize should be used instead. However, there are many programs out there that still use the old API, so the old functions are maintained for backwards compatibility purposes. Hence the man page. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by wweng＠kencast.com 02 Apr '07

02 Apr '07

Full_Name: Wei Weng Version: 2.3.19 OS: Linux(Fedora 5) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.120.101.108) I don't know if the people who are in charge to build a RPM are paying attention to what they are doing or not. You can do a man ldap_init, and then look at /usr/include/ldap.h for the function definition. I am not a LDAP expert or anything close to that. But it seems to me that function called ldap_init has already been replaced by the function called ldap_initialize, and they take even different set of parameters. And yet the manpage not only didn't reflect that change, but enforce the wrong idea of using ldap_init function by having ldap_init in manpages. An extremely poor job done by the package maintainer.

1 0

Re: (ITS#4901) malloc/free mismatches in ldapadd
by quanah＠stanford.edu 30 Mar '07

30 Mar '07

--On Saturday, March 31, 2007 12:54 AM +0000 quanah(a)stanford.edu wrote: > --On Friday, March 30, 2007 2:25 PM +0000 chris.ridd(a)isode.com wrote: > >> Full_Name: Chris Ridd >> Version: 2.3.34 >> OS: Windows >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (62.3.217.250) >> >> >> On Windows, it is important that mallocs done in one DLL are balanced by >> frees done from the same DLL. Failure to do this consistently leads to >> heap corruption. >> >> This was observed to occur in several places in ldapadd - several buffers >> allocated by ber_memfree() were freed using free(). >> >> Our customer has successfully used a version of ldapadd on Windows >> containing this patch (and the one in ITS 4900.) > > Thanks, testing. --- openldap-2.3.34/clients/tools/common.c.orig Fri Mar 30 15:17:32 2007 +++ openldap-2.3.34/clients/tools/common.c Fri Mar 30 15:21:42 2007 @@ -1244,7 +1244,7 @@ crit ? "critical " : "" ); } - free( ctrls ); + ldap_controls_free( ctrls ); if ( crit ) { exit( EXIT_FAILURE ); } Just to note, this part of the patch is bad. ctrls is a pointer to an array of controls, not an array of controls itself. Therefore, the use of "free" here is appropriate. Using ldap_controls_free results in segfaults. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4901) malloc/free mismatches in ldapadd
by quanah＠stanford.edu 30 Mar '07

30 Mar '07

--On Friday, March 30, 2007 2:25 PM +0000 chris.ridd(a)isode.com wrote: > Full_Name: Chris Ridd > Version: 2.3.34 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.3.217.250) > > > On Windows, it is important that mallocs done in one DLL are balanced by > frees done from the same DLL. Failure to do this consistently leads to > heap corruption. > > This was observed to occur in several places in ldapadd - several buffers > allocated by ber_memfree() were freed using free(). > > Our customer has successfully used a version of ldapadd on Windows > containing this patch (and the one in ITS 4900.) Thanks, testing. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4900) command-line utils crash
by quanah＠stanford.edu 30 Mar '07

30 Mar '07

--On Friday, March 30, 2007 2:09 PM +0000 chris.ridd(a)isode.com wrote: > Full_Name: Chris Ridd > Version: 2.3.34 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.3.217.250) > > > On Windows, the ldapadd tool often crashes while parsing the command-line > arguments. Hi Chris, We formally dropped support for MSVC a long time ago. That being said, working build of OpenLDAP was accomplished with MSVCC a few months ago without hitting this issue. Which version of MSVC is being used, and please doublecheck the conditions spelled out in the comments in <ldap_cdefs.h>, where it starts with "Support for Windows DLLs". Also, instead of declaring things as extern, does changing LDAP_LIBC_V to LDAP_LUTIL_V resolve your issue? --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4901) malloc/free mismatches in ldapadd
by chris.ridd＠isode.com 30 Mar '07

30 Mar '07

Full_Name: Chris Ridd Version: 2.3.34 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.3.217.250) On Windows, it is important that mallocs done in one DLL are balanced by frees done from the same DLL. Failure to do this consistently leads to heap corruption. This was observed to occur in several places in ldapadd - several buffers allocated by ber_memfree() were freed using free(). Our customer has successfully used a version of ldapadd on Windows containing this patch (and the one in ITS 4900.) Patch follows: --- openldap-2.3.34/clients/tools/common.c.orig Fri Mar 30 15:17:32 2007 +++ openldap-2.3.34/clients/tools/common.c Fri Mar 30 15:21:42 2007 @@ -163,7 +163,7 @@ N_(" -n show what would be done but don't actually do it\n"), N_(" -O props SASL security properties\n"), N_(" -p port port on LDAP server\n"), -N_(" -P version procotol version (default: 3)\n"), +N_(" -P version protocol version (default: 3)\n"), N_(" -Q use SASL Quiet mode\n"), N_(" -R realm SASL realm\n"), N_(" -U authcid SASL authentication identity\n"), @@ -1244,7 +1244,7 @@ crit ? "critical " : "" ); } - free( ctrls ); + ldap_controls_free( ctrls ); if ( crit ) { exit( EXIT_FAILURE ); } --- openldap-2.3.34/clients/tools/ldapmodify.c.orig Fri Mar 30 15:19:34 2007 +++ openldap-2.3.34/clients/tools/ldapmodify.c Fri Mar 30 15:21:07 2007 @@ -389,8 +389,8 @@ fprintf( rejfp, "\n%s\n", rejbuf ); } - if (rejfp) free( rejbuf ); - free( rbuf ); + if (rejfp) ber_memfree( rejbuf ); + ber_memfree( rbuf ); } #ifdef LDAP_GROUP_TRANSACTION @@ -519,7 +519,7 @@ printf(_("%s: skipping change record for entry: %s\n"), prog, dn); printf(_("\t(LDAP host/port does not match replica: lines)\n")); - free( dn ); + ber_memfree( dn ); ber_memfree( type ); ber_memfree( val.bv_val ); return( 0 ); @@ -727,13 +727,13 @@ } if ( dn != NULL ) { - free( dn ); + ber_memfree( dn ); } if ( newrdn != NULL ) { - free( newrdn ); + ber_memfree( newrdn ); } if ( newsup != NULL ) { - free( newsup ); + ber_memfree( newsup ); } if ( pmods != NULL ) { ldap_mods_free( pmods, 1 );

1 0

(ITS#4900) command-line utils crash
by chris.ridd＠isode.com 30 Mar '07

30 Mar '07

Full_Name: Chris Ridd Version: 2.3.34 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.3.217.250) On Windows, the ldapadd tool often crashes while parsing the command-line arguments. This is due to a defect in the way the optarg (et al) variables are declared in ac/unistd.h. When tools/common.c includes that file, the 4 variables end up being declared as being "imported" from a DLL. However they're *actually* present in a static archive that's linked into the ldapadd executable, which is apparently not the same sort of thing. (Visual Studio's compiler warns about inconsistent linkage :-) As a result, the code in getopt.c thinks that optarg is a variable at one address, and the code calling getopt() think that optarg is a variable at a *different* address (NULL in my test rig). Clearly that's not right, and it causes a variety of issues: -D <dn> copies optarg using strdup(NULL), which returns NULL. -w <passwd> scribbles over the passwd string, which crashes doing a *optarg because optarg is NULL. A simple fix is to redeclare the 4 variables as just "extern" instead of LDAP_LIBC_V. Diff follows... --- openldap-2.3.34/include/ac/unistd.h.orig Fri Mar 30 15:05:49 2007 +++ openldap-2.3.34/include/ac/unistd.h Fri Mar 30 15:06:10 2007 @@ -54,8 +54,8 @@ #else /* assume we need to declare these externs */ - LDAP_LIBC_V (char *) optarg; - LDAP_LIBC_V (int) optind, opterr, optopt; + extern char * optarg; + extern int optind, opterr, optopt; #endif /* use lutil file locking */

1 0

Re: (ITS#4890) Enhancement: Default Values overlay (patch)
by quanah＠stanford.edu 29 Mar '07

29 Mar '07

--On Thursday, March 22, 2007 5:25 PM +0000 docelic(a)mail.inet.hr wrote: > Full_Name: Davor Ocelic > Version: CVS-HEAD > OS: Linux > URL: http://www.hcoop.net/~docelic/openldap-slapd.overlays.defvals.patch > Submission from: (NULL) (213.147.110.16) > > > > Hello, > > Attached is a patch which adds a "Default Attribute Values" functionality > to OpenLDAP. It is implemented as an overlay named "defvals", and the > patch is done against cvs-head of today. > > Complete documentation is included in the slapo-defvals(5) manual page. > The overlay code itself is commented as well, as a help for others writing > overlays. > > Feel free to trim comments or improve code as you see fit. Hi Davor, I believe you'll need to complete the attribution bit detailed here: <http://www.openldap.org/devel/contributing.html> for this to be included. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs