- openldap-bugs - openldap.org

Re: (ITS#5328) backends sending/setting results
by ando＠sys-net.it 16 Jan '08

16 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > back-relay's be_extended could send a result, but be_extended should > only set/return it and leave it to the frontend to send it. > Just fixed by Pierangelo. > > Looking at the code, some overlays also send results when used as > be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay. > > > More about back-relay: > > - it fails to send anything if the Delete operation is not supported. > > - be_abandon, be_chk_referrals and be_operational can return either an > LDAP result code, or 0 or 1 (which become success and operationError > if they get used as result codes). I don't know if that matters. > > Back-relay operations can be factored out to something like this: > > int > relay_back_op( > Operation *op, > SlapReply *rs, > BackendDB *bd, > BI_op_func *func, > Fail_Type fail_mode ) > { > int rc = fail_mode; > > if ( func ) { > BackendDB *be = op->o_bd; > slap_callback cb; > > relay_back_add_cb( &cb, op ); > > op->o_bd = bd; > rc = func( op, rs ); > op->o_bd = be; > > if ( op->o_callback == &cb ) { > op->o_callback = op->o_callback->sc_next; > } > > } else if ( fail_mode > Fail_1 ) { > rc = rs->sr_err = LDAP_UNWILLING_TO_PERFORM; > rs->sr_text = "operation not supported within naming context"; > if ( fail_mode == Fail_send ) { > send_ldap_result( op, rs ); > rc = 1; > } > } > > return rc; > } > > ... > return relay_back_op( op, rs, bd, bd->be_bind, Fail_send ); > (void) relay_back_op( op, rs, bd, bd->be_unbind, Fail_0 ); return 0; > return relay_back_op( op, rs, bd, bd->be_search, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_compare, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_modify, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_modrdn, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_add, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_delete, Fail_send ); > return relay_back_op( op, rs, bd, bd->be_abandon, Fail_1 ); > return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send ); ^^^ cancel should __NOT__ send response, since it's an extended operation. On the contrary, it should set op->o_cancel if it couldn't relay the operation, otherwise the cancel thread would yield forever. > return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling ); > return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 ); > return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 ); I like the idea, but that's slightly too simple. The reason I didn't try to synthesize calls like that was the need to also handle more complex combinations. For this reason, I'm actually considering the use of a mask to fine-grain drive the behavior of the helper. 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 ---------------------------------------

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 16 Jan '08

16 Jan '08

I wrote: > Back-relay operations ...as of today... > can be factored out to something like this: > (...) Oops, I forgot: typedef enum { Fail_0 = 0, Fail_1 = 1, Fail_unwilling, Fail_send } Fail_Type; -- Hallvard

1 0

(ITS#5329) back-ldif deadlock
by h.b.furuseth＠usit.uio.no 16 Jan '08

16 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard back-ldif deadlocks on Modify access control in test006-acls (modified to support back-ldif). It tries to lock li_rdwr for both write (for the modify) and read (reading entries for access control) at the same time. However the manpage says The LDIF backend does not honor any of the access control semantics described in slapd.access(5). Only read (=r) access to the entry pseudo-attribute and to the other attribute values of the entries returned by the search operation is honored, which is performed by the frontend. Should the manpage be updated (and maybe more acl calls be added), or should the acl call be removed? Assuming the acl call should be there, one simple fix could be to introduce a 'li_wlock' mutex, lock it early on LDAP update operations, and delay locking li_rdwr until the operation is about to update the database. That can also get rid of the entry2str_mutex abuse. I've written a patch and it works, but something broke test045. Will look again later, if we are to keep the acl call(s).

1 0

(ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 16 Jan '08

16 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard back-relay's be_extended could send a result, but be_extended should only set/return it and leave it to the frontend to send it. Just fixed by Pierangelo. Looking at the code, some overlays also send results when used as be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay. More about back-relay: - it fails to send anything if the Delete operation is not supported. - be_abandon, be_chk_referrals and be_operational can return either an LDAP result code, or 0 or 1 (which become success and operationError if they get used as result codes). I don't know if that matters. Back-relay operations can be factored out to something like this: int relay_back_op( Operation *op, SlapReply *rs, BackendDB *bd, BI_op_func *func, Fail_Type fail_mode ) { int rc = fail_mode; if ( func ) { BackendDB *be = op->o_bd; slap_callback cb; relay_back_add_cb( &cb, op ); op->o_bd = bd; rc = func( op, rs ); op->o_bd = be; if ( op->o_callback == &cb ) { op->o_callback = op->o_callback->sc_next; } } else if ( fail_mode > Fail_1 ) { rc = rs->sr_err = LDAP_UNWILLING_TO_PERFORM; rs->sr_text = "operation not supported within naming context"; if ( fail_mode == Fail_send ) { send_ldap_result( op, rs ); rc = 1; } } return rc; } ... return relay_back_op( op, rs, bd, bd->be_bind, Fail_send ); (void) relay_back_op( op, rs, bd, bd->be_unbind, Fail_0 ); return 0; return relay_back_op( op, rs, bd, bd->be_search, Fail_send ); return relay_back_op( op, rs, bd, bd->be_compare, Fail_send ); return relay_back_op( op, rs, bd, bd->be_modify, Fail_send ); return relay_back_op( op, rs, bd, bd->be_modrdn, Fail_send ); return relay_back_op( op, rs, bd, bd->be_add, Fail_send ); return relay_back_op( op, rs, bd, bd->be_delete, Fail_send ); return relay_back_op( op, rs, bd, bd->be_abandon, Fail_1 ); return relay_back_op( op, rs, bd, bd->be_cancel, Fail_send ); return relay_back_op( op, rs, bd, bd->be_extended, Fail_unwilling ); return relay_back_op( op, rs, bd, bd->be_chk_referrals, Fail_0 ); return relay_back_op( op, rs, bd, bd->be_operational, Fail_1 );

1 0

Re: (ITS#5308) test034-translucent crashes with back-ldif
by h.b.furuseth＠usit.uio.no 15 Jan '08

15 Jan '08

ando(a)sys-net.it writes: > It is now fixed in HEAD; please test. Please, also check and test for > any side-effect introduced by the fix, as it impacts all calls to > str2entry (many, I believe). Tested, works fine so far. Haven't looked much for those side effects though. Would need to dig in the code and then construct test cases for it, I guess. -- Hallvard

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by hyc＠symas.com 15 Jan '08

15 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I understand that unfortunately in slapadd this would require either >> to keep track of inserted DNs, or to issue quite a few be_entry_get(), >> possibly resulting in a sensible penalization. Perhaps it could be an >> option, relying on the fact that slapadd is basically intended to >> operate on "well-behaved" data? > > It had better, since slapadd accepts entries out of order. (It returns > failure at the end if some child has not received a parent.) Seems like this only needs to be a feature of LDAP Add processing; slapadd should pretty much take its input verbatim. -- -- 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#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 15 Jan '08

15 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I understand that unfortunately in slapadd this would require either >> to keep track of inserted DNs, or to issue quite a few be_entry_get(), >> possibly resulting in a sensible penalization. Perhaps it could be an >> option, relying on the fact that slapadd is basically intended to >> operate on "well-behaved" data? > > It had better, since slapadd accepts entries out of order. (It returns > failure at the end if some child has not received a parent.) This could be treated specially by performing renames as soon as info becomes available. This pushes more and more towards making this either an option or a no-go for slapadd (i.e. rely on LDIF massaging to have things nice). Note that having data not compliant with the requirement of this ITS would by no means be a violation of LDAP nor cause any operational issue to slapd. It would just be a matter of having more well-behaved data if this does not impact too much operations (and it shouldn't for run-time adds, since we already lookup the parent when adding an entry). 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 ---------------------------------------

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by h.b.furuseth＠usit.uio.no 15 Jan '08

15 Jan '08

ando(a)sys-net.it writes: > I understand that unfortunately in slapadd this would require either > to keep track of inserted DNs, or to issue quite a few be_entry_get(), > possibly resulting in a sensible penalization. Perhaps it could be an > option, relying on the fact that slapadd is basically intended to > operate on "well-behaved" data? It had better, since slapadd accepts entries out of order. (It returns failure at the end if some child has not received a parent.) -- Hallvard

1 0

Re: (ITS#5327) slapo-constraint seg faults on regex
by ando＠sys-net.it 15 Jan '08

15 Jan '08

michael(a)stroeder.com wrote: > Guess it's not that helpful: No problem, easy to reproduce (as much as easy to fix :) 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 ---------------------------------------

1 0

Re: (ITS#5327) slapo-constraint seg faults on regex
by michael＠stroeder.com 15 Jan '08

15 Jan '08

Guess it's not that helpful: (gdb) bt full #0 0x0815903b in ldap_pvt_sasl_mutex_dispose () No symbol table info available. #1 0x0000002c in ?? () No symbol table info available. #2 0x00000000 in ?? () No symbol table info available. (gdb)

1 0

(ITS#5327) slapo-constraint seg faults on regex
by michael＠stroeder.com 15 Jan '08

15 Jan '08

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.61.186) slapo-constraint seg faults if slapd.conf contains this line: constraint_attribute gender regex ^[0129]?$ The very same config works with RE24 just fine.

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 15 Jan '08

15 Jan '08

ando(a)sys-net.it wrote: > I think it is reasonable to reconstruct an entry's DN by using the parent's DN > and the entry's RDN. The rationale consists in ensuring the tree naming is as > uniform as possible. I understand that unfortunately in slapadd this would require either to keep track of inserted DNs, or to issue quite a few be_entry_get(), possibly resulting in a sensible penalization. Perhaps it could be an option, relying on the fact that slapadd is basically intended to operate on "well-behaved" data? 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 ---------------------------------------

1 0

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by ando＠sys-net.it 14 Jan '08

14 Jan '08

[Please CC messages to the ITS] Tim Bishop wrote: > On Sat, Jan 12, 2008 at 10:07:57AM +0100, Pierangelo Masarati wrote: >> tim(a)bishnet.net wrote: >> >>> For reference, it's because my libdb is built using --with-uniquename. >>> This means the function name is actually __lock_getlocker_4006. >>> >>> I didn't see this in the documentation. OpenLDAP should either correctly >>> handle this case, or document that it's not supported. >> I think using that option is a Bad Idea (TM); it is the Wrong Solution >> to the problem of having multiple coexisting versions of a library. In >> any case, adding support for that feature would be problematic and >> definitely prone to user (and developer) errors, since the value used to >> make names unique is not exposed in any header file, so it would have to >> be manually defined. There are tons of (sysadmin side) ways to make >> sure the right library is loaded, so I vote against supporting this >> feature. Of course, I'm fine about documenting that --with-uniquename >> is not supported. > > I notice lots of other functions have a mapping in the bdb header file > so you don't need to know the unique value. Is this issue occuring > because the __lock_getlocker function is not meant to be called by > external applications? The mapping depends on the version of Berkeley, so mapping names would require to know what the mapping is; but as far as I can see, it does not provide any means to expose it. Other mappings are basically needed to work around uneven cross-version naming issues in Berkeley, or for OpenLDAP internal purposes, like separating back-bdb and back-hdb names. As Hallvard pointed out, probably that function was not meant to be exposed, since it's not declared in Berkeley's headers, but unfortunately OpenLDAP code seems to need it. Of course, you can still manually CPPFLAGS=-D__lock_getlocker=__lock_getlocker_4006 to workaround your issue. 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 ---------------------------------------

1 0

(ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 13 Jan '08

13 Jan '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I think it is reasonable to reconstruct an entry's DN by using the parent's DN and the entry's RDN. The rationale consists in ensuring the tree naming is as uniform as possible. p.

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 13 Jan '08

13 Jan '08

Howard Chu writes: > The outcome of the original discussion, which Kurt again reminded me > of today, was that ldapmodify should quit its guessing games and just > accept valid LDIF input. All I see in the -devel discussion is about bugs in the parser. I see nothing about removing the default "add:"/"replace:" derived from "changetype:", though perhaps it's in the off-list discussion it refers to. > The description of the exceptions in the manpage seemed imply they > were there to accommodate slurpd users, who needed a mechanism for > applying failed updates to a target server. Now that all slurpd/replog > support has been dropped, there really is no more justification for > these exceptions. That's not my impression, nor my recollection of the -r option. The manpage lists some differences from ldif format - replog, and defaulting changetype, add/replace. But they do not seem related. Not in the old code either; removing replog code can be done cleanly and does not interfere with those defaults. BTW I was wrong about when -r was removed. Seems to have been in the middle of the 2.0 branch; I only checked the beginning. ldapmodify rev 1.97, May 2 2001 "Clean up some logic, based upon Novell patches". I see a small patch from Novell shortly before that, ITS#1075, about a bug in the -r option. The "patches" referred to means more I've missed, I guess. >> As far as I can tell Logschema doesn't support full LDIF modify though. >> reqMod is unordered, so one cannot make two modifications to the same >> attribute. E.g. "delete: foo" followed by "replace: foo". > > I suppose reqMod should be made ordered. My point about logschema is that > reqMod's syntax doesn't require separators/terminators or as many redundant > attribute references. > > attr:- foo > attr:+ bar > > is a far more efficient representation than > > delete: attr > attr: foo > - > add: attr > attr: bar > - Which is why I want the old 'replace:' default back... With a doc warning that one must use the verbose LDIF format if one wants to not worry about attribute names like "increment" or "changetype". > The logschema format is also easily grep-able without resorting to grep > windowing and other such hassles. And that was roughly the old ldapmodify format. See manpage umich ldap-3.3/doc/man/man1/ldapmodify.1. I wonder why we removed it. There are a few weird LDAP change requests that do not map to that format, e.g. add: cn cn: foo - add: cn cn: bar - but that could have been fixed simply by allowing a '-' line as in the current format. >> Maybe it's time to take this to the ldapext list and hear what others >> do. > > This is really getting off topic, unless you're suggesting that we > spec this for a new version of LDIF. Not really, more the opposite - if we just relax some restrictions on the old format ldapmodify accepted before, that's fine. But otherwise, if we end up inventing a new way to parse ldifs rather than just accepting more of what the code accepted before, I think it'd be best to see what others do first. And if so we might as well go further. I don't suggest that as part of resolving this ITS, certainly. -- Regards, Hallvard

1 0

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by h.b.furuseth＠usit.uio.no 13 Jan '08

13 Jan '08

ando(a)sys-net.it writes: > (...) There are tons of (sysadmin side) ways to make > sure the right library is loaded, so I vote against supporting this > feature. Of course, I'm fine about documenting that --with-uniquename > is not supported. configure should in any case check for __lock_getlocker(), since it's not a documented Berkeley DB function. Note that their headers do not declare it, OpenLDAP back-bdb.h does. -- Regards, Hallvard

1 0

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by ando＠sys-net.it 12 Jan '08

12 Jan '08

tim(a)bishnet.net wrote: > For reference, it's because my libdb is built using --with-uniquename. > This means the function name is actually __lock_getlocker_4006. > > I didn't see this in the documentation. OpenLDAP should either correctly > handle this case, or document that it's not supported. I think using that option is a Bad Idea (TM); it is the Wrong Solution to the problem of having multiple coexisting versions of a library. In any case, adding support for that feature would be problematic and definitely prone to user (and developer) errors, since the value used to make names unique is not exposed in any header file, so it would have to be manually defined. There are tons of (sysadmin side) ways to make sure the right library is loaded, so I vote against supporting this feature. Of course, I'm fine about documenting that --with-uniquename is not supported. 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 ---------------------------------------

1 0

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by tim＠bishnet.net 11 Jan '08

11 Jan '08

On Fri, Jan 11, 2008 at 12:30:42PM -0800, Howard Chu wrote: > tim(a)bishnet.net wrote: > >Full_Name: Tim Bishop > >Version: 2.4.7 > >OS: Solaris 9 > >URL: > >Submission from: (NULL) (129.12.3.176) > > > > > >I'm having trouble building 2.4.7 against bdb 4.6.21. The build error is: > > > >Undefined first referenced > > symbol in file > >__lock_getlocker libbackends.a(bdbinit.o) > >ld: fatal: Symbol referencing errors. No output written to .libs/slapd > >collect2: ld returned 1 exit status > >make[2]: *** [slapd] Error 1 > > > >Is bdb 4.6.21 supported? > > Yes. > > It looks like either you're linking against the wrong version of libdb, or > something is odd in the way your libdb was built. There's no OpenLDAP > software bug here, this ITS will be closed. Use the -software mailing list > for questions about working with the source. For reference, it's because my libdb is built using --with-uniquename. This means the function name is actually __lock_getlocker_4006. I didn't see this in the documentation. OpenLDAP should either correctly handle this case, or document that it's not supported. Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984

1 0

Re: (ITS#5325) Build error: __lock_getlocker undefined symbol
by hyc＠symas.com 11 Jan '08

11 Jan '08

tim(a)bishnet.net wrote: > Full_Name: Tim Bishop > Version: 2.4.7 > OS: Solaris 9 > URL: > Submission from: (NULL) (129.12.3.176) > > > I'm having trouble building 2.4.7 against bdb 4.6.21. The build error is: > > Undefined first referenced > symbol in file > __lock_getlocker libbackends.a(bdbinit.o) > ld: fatal: Symbol referencing errors. No output written to .libs/slapd > collect2: ld returned 1 exit status > make[2]: *** [slapd] Error 1 > > Is bdb 4.6.21 supported? Yes. > > Is there a configure option to force a particular version of bdb? Read the INSTALL document. It looks like either you're linking against the wrong version of libdb, or something is odd in the way your libdb was built. There's no OpenLDAP software bug here, this ITS will be closed. Use the -software mailing list for questions about working with the source. -- -- 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#5308) test034-translucent crashes with back-ldif
by ando＠sys-net.it 11 Jan '08

11 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > "./run -b ldif test034-translucent" crashes in str2entry2() at: > entry.c:298: if( ad_prev->ad_type->sat_equality && > because ad_prev == NULL - which got through due to this statement: > entry.c:278: if (( ad_prev && ad != ad_prev ) || ( i == lines )) { The real bug here is that the loop for attribute normalizations is run also in case there is no attrs. In fact, the same error shows up if you craft a shell backend (back-shell, back-perl) so that an LDIF only containing a DN is returned. It is now fixed in HEAD; please test. Please, also check and test for any side-effect introduced by the fix, as it impacts all calls to str2entry (many, I believe). 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 ---------------------------------------

1 0

(ITS#5325) Build error: __lock_getlocker undefined symbol
by tim＠bishnet.net 11 Jan '08

11 Jan '08

Full_Name: Tim Bishop Version: 2.4.7 OS: Solaris 9 URL: Submission from: (NULL) (129.12.3.176) I'm having trouble building 2.4.7 against bdb 4.6.21. The build error is: Undefined first referenced symbol in file __lock_getlocker libbackends.a(bdbinit.o) ld: fatal: Symbol referencing errors. No output written to .libs/slapd collect2: ld returned 1 exit status make[2]: *** [slapd] Error 1 Is bdb 4.6.21 supported? Is there a configure option to force a particular version of bdb? Thanks, Tim.

1 0

Re: (ITS#5324) Access violation on Windows due to %n in format strings
by hyc＠symas.com 11 Jan '08

11 Jan '08

ghenry(a)suretecsystems.com wrote: > > In libraries/libldap/url.c, function ldap_url_desc2str, there are a > couple of >> sprintfs that use %n in their format strings to return position information. >> The latest Windows SDKs have heavily deprecated %n and its use now results in an >> unfortunate access violation and process crash. > > ldap_url_desc2str calls desc2str, which is where the sprintfs are. > > There's actually only one in an if/else in that function. > > This is the same for the latest 2.3 libldap and 2.4 libldap > > but this doesn't really answer your question. Already fixed in HEAD. -- -- 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#5324) Access violation on Windows due to %n in format strings
by ghenry＠suretecsystems.com 11 Jan '08

11 Jan '08

> In libraries/libldap/url.c, function ldap_url_desc2str, there are a couple of > sprintfs that use %n in their format strings to return position information. > The latest Windows SDKs have heavily deprecated %n and its use now results in an > unfortunate access violation and process crash. ldap_url_desc2str calls desc2str, which is where the sprintfs are. There's actually only one in an if/else in that function. This is the same for the latest 2.3 libldap and 2.4 libldap but this doesn't really answer your question. > > We've added a call to "_set_printf_count_output(1)" in libraries/libldap/init.c > function ldap_int_initialize() to re-enable %n so we're sufficiently worked > around for the moment. We're happy with our own workaround so we're not asking > for any kind of quick turnaround on this issue. If you want to fix this, please > do so in your own time and in your own way. You can consider this a courtesy > report only. > > If you decide not to fix this, please let me know because we'll need to add a > formal test case to our regression suites to make sure we don't resurrect the > issue when we upgrade our OpenLDAP clients. > > The msdn.microsoft.com website has the details of their proprietary function and > SDK versions where it's required in case you want to use our approach. I > included the URL so that you can get to it directly without going through MSDN's > searching. My own opinion is finding a way to do without the %n is probably > better and would result in fewer ifdefs in the code (always a plus in my book) > and less Microsoft specific code lurking around to bite us later. > > We did pull down 2.3.39 and our tech that looked at the code tells me the %n's > are still there and there's no _set_printf_count_output call so we think the > problem still exists in the latest version. Give me a virtual slap if I've got > this wrong. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by ghenry＠OpenLDAP.org 11 Jan '08

11 Jan '08

ghenry(a)suretecsystems.com wrote: > joshua(a)itsecureadmin.com wrote: >> Full_Name: Joshua Miller >> Version: 2.4.7 >> OS: CentOS 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (198.134.96.10) >> >> >> OL Version 2.4.7 >> Berkely DB 4.6 >> OS CentOS 5 >> >> Command: slapindex >> >> ISSUE: >> >> When attempting to generate cn=config from a configuration file using slapindex, >> no cn=config is generated: >> >> # cd /etc/openldap >> # mkdir slapd.d >> # /usr/sbin/slapindex -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d >> # echo $? >> 0 >> >> Program exits without error. >> >> # ls /etc/openldap/slapd.d >> >> Subsequently, running this command immediately after generates the appropriate >> cn=config: >> >> # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d >> config file testing succeeded >> # ll slapd.d >> total 8 >> drwxr-x--- 4 root root 4096 Jan 10 13:07 cn=config >> -rw------- 1 root root 1097 Jan 10 13:07 cn=config.ldif >> # >> >> > > man slapindex does indeed so you can do this... > "does indeed say you can do this..." that should read. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5321) slapindex fails to create cn=config from configuration file
by ghenry＠suretecsystems.com 11 Jan '08

11 Jan '08

joshua(a)itsecureadmin.com wrote: > Full_Name: Joshua Miller > Version: 2.4.7 > OS: CentOS 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.134.96.10) > > > OL Version 2.4.7 > Berkely DB 4.6 > OS CentOS 5 > > Command: slapindex > > ISSUE: > > When attempting to generate cn=config from a configuration file using slapindex, > no cn=config is generated: > > # cd /etc/openldap > # mkdir slapd.d > # /usr/sbin/slapindex -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d > # echo $? > 0 > > Program exits without error. > > # ls /etc/openldap/slapd.d > > Subsequently, running this command immediately after generates the appropriate > cn=config: > > # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d > config file testing succeeded > # ll slapd.d > total 8 > drwxr-x--- 4 root root 4096 Jan 10 13:07 cn=config > -rw------- 1 root root 1097 Jan 10 13:07 cn=config.ldif > # > > man slapindex does indeed so you can do this... -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs