- openldap-bugs - openldap.org

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

hyc(a)symas.com writes: > h.b.furuseth(a)usit.uio.no wrote: >> * When a thread is finishing, make it go active for context_reset(). >> Should make slapi module destructors safer, and I don't see that it >> can hurt. > > I don't understand this. Let me dig a bit back in the ITS... "context_reset() can call connection_fake_destroy(), which via slapi_int_free_object_extensions() calls slapi module destructors, which can do who-knows-what." >> * I'd like to rename thread contexts to tasks(?) and user contexts back >> to contexts (as in RE23). The current terminology is confusing. > > I don't care about this either way. Then I will. I still confuse myself sometimes, and I certainly would if I came back to this code next year. >> (...) > Never use malloc unless absolutely necessary. We have enough problems > with heap fragmentation already. Aha. OK. >> * Scheduling: If several threads call pool_pause(), then once there is a >> pause tpool does not schedule them all. They could get handled then, >> or another thread could undo the pause so tpool would wait to pause >> again. Is that deliberate? > > I don't understand the question. The point of the pause is to prevent > any other thread (in the pool) from running. Why should tpool schedule > any other threads at this point? Two threads call pool_pause(). Eventually the pool gets paused, and one pool_pause() call returns. When that thread calls pool_resume(), the other thread waiting in pool_pause() may or may not get scheduled. >> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can >> represent the same thread ID: TID_HASH() would give different hashes >> for the same thread, and pool_context() stops searching when it hits >> a slot with ctx == NULL. (My previous bug report was a bit wrong.) > > How can a single thread ID be represented by multiple bit patterns? A struct/union with padding bytes seems the least unlikely possibility. A pointer in hardware where several address representations map to the same physical address, and the compiler handles that by normalizing pointers when they are compared/subtracted. Like DOS "huge" pointers would have been if the compiler normalized them when comparing them instead of when incrementing/decrementing them. 20-bit address bus, 32-bit pointers, physical address = 16 * <segment half of pointer> + <offset half of pointer>. Or, not that I take this too seriously: A pthread implementation which uses e.g. a 32-bit integer type for thread IDs but just ignores the top 22 bits. The Posix spec seems to allow that, and thread IDs are to be compared with pthread_equal(). >> The best fix would be to use use real thread-specific data instead. >> Just one key with the ctx for now, that minimizes the changes. OTOH >> it also means we'll do thread-specific key lookup twice - first in >> pthread to get the ctx, and then in ltu_key[] to find our data. >> Anyway, I said I'd do that later but might as well get on with it, >> at least for pthreads. Except I don't know if that's OS-dependent >> enough that it should wait for RE24? > > The best fix may be to just use the address of the thread's stack as the > thread ID. That's actually perfect for our purpose. How does a function called from somewhere inside the thread know that address? That's almost what the user context is, and thus what thread_keys[] maps the thread ID to. >> - thread_keys is a poor hash table implementation with a poor hash >> function. > > Ideally it would not be a hash table at all, but a direct lookup based > on the thread ID. If we can. See above. Anyway, I don't know why I keep kvetching about the hash table implementation. I'll just make it chained. As I finally figured out, that can be done without mallocs. Solves the multi-pool problem too. >> * I wonder if there are long-lived ldap_pvt_thread_cond_wait(), >> [r]mutex_lock() or rdwr_[rw]lock() calls which should make the thread >> go inactive first (after waiting for any pause to finish), so that >> (a) a pool_pause() will not block waiting for them, and >> (b) all threads in the pool can't be blocked in long waits without >> tpool knowing about it. > > Long-lived lock calls would be a quite noticeable bug. This seems to be > a non-issue. Well, it'd have to be with code which is very rarely executed, or unusual configurations. But yes, I feel relaxed enough about it. >> * back-bdb/tools.c uses pool_submit() to start long-lived threads: >> (...) > Tool threads are completely separate from slapd threads. This is not an > issue. Fine. I don't understand that in this context, but I'll take your word for it:-) >> * slapd/bconfig.c maintains its own idea of the max number of threads >> in connection_pool_max and slap_tool_thread_max, which does not match >> tpool's idea if the limit is <=0 or larger than LDAP_MAXTHR. >> >> Since slapd acts on its own count, I imagine that can cause breakage. >> Simplest fix might be to set max #threads and then read it back, >> I haven't checked. Would need to return LDAP_MAXTHR instead of 0 >> for "as many as allowed". Note however also the issue above: >> tpool's idea of actually available threads can be too high too. > > The practical limits are actually pretty low. Even if you're on a 1024 > processor machine with many terabytes of RAM, it's not a good idea to > have many thousands of threads... Scheduler overhead would overshadow > any useful work. OK. I forgot how much RAM a slapd thread requires. But then it won't hurt to give slapd a max limit lower than LDAP_MAXTHR either. >> * I said my new ltp_pause waits might be too aggressive. Maybe I should >> clarify: I don't see any instances where they can be dropped, but it's >> possible that slapd expects pauses to be less aggressive somewhere. > > I don't understand this comment. Clarifying the clarification: I don't know slapd well enough to know if the extra pauses do something bad to it. >> Oh, the comment /* no open threads at all?!? */: That's not strange. >> Happens in the first pool_submit() call(s) if thread_create() fails. >> Though in that case there was no danger of removing the wrong ctx >> from ltp_pending_list after all (fixed in rev 1.63). > > (Sure, but thread_create() should never fail if you have a sane > configuration.) And if the rest of the machine doesn't run wild. I imagine thread_create() can fail when fork() can fail on some OSes. -- Regards, Hallvard

1 0

Re: (ITS#5003) issue about upper_needs_cast
by ando＠sys-net.it 09 Jun '07

09 Jun '07

caojunliang(a)huawei.com wrote: > when I set the option upper_needs_cast as Yes.It only takes effect on id_query > when adding an entry,but does not take effect on child id query when deleting an > entry. > > I found that in the src file back-sql/init.c > > line 374 --379 > > there are not operation about upper cast. > > I want to know if what I think is right. Not clear what's your point. "upper_needs_cast" is a hack to work around the fact that some RDBMSes need an explicit cast before passing a literal into whatever "uppercase" function they provide. Can you point out what's the problem and what's the expected behavior? I don't see any literal passed to the query that looks up the parent's and that needs any special treatment. A log of the offending operation, and an example of what you'd consider correct, would help. 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#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 09 Jun '07

09 Jun '07

This is now made consistent in HEAD: the inability to register custom monitor stuff always results in a failure. Note that the software provides different means to prevent this feature: a) allow anonymous read access to the monitor database b) define a rootdn (even without any possibility to auth) for the monitor database c) disable monitoring for all bdb/hdb databases 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#5005) test017 fails
by ando＠sys-net.it 09 Jun '07

09 Jun '07

dieter(a)dkluenter.de wrote: The problem is in slap_parse_sync_cookie(); when no cookie is passed, a string containing "rid=001" is parsed. The parser expects it to end with a comma. If passing "rid=001" is correct, the fix is trivial: instead of checking for (*next != ','), check for (*next && *next != ','). Index: servers/slapd/ldapsync.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/ldapsync.c,v retrieving revision 1.42 diff -u -r1.42 ldapsync.c --- servers/slapd/ldapsync.c 18 May 2007 12:46:52 -0000 1.42 +++ servers/slapd/ldapsync.c 9 Jun 2007 09:42:24 -0000 @@ -180,7 +180,10 @@ if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); - if ( next == rid_ptr || next > end || *next != ',' ) { + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { @@ -194,7 +197,10 @@ if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ], &next, 16 ); - if ( next == rid_ptr || next > end || *next != ',' ) { + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { I'm not committing this fix because I'm not sure it doesn't break anything else. 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#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 09 Jun '07

09 Jun '07

ando(a)sys-net.it wrote: > The difference is that if the monitor database comes first, it's already > open when the bdb tries to register its custom monitor stuff. So it can > barf out when the addition fails because of no enough permissions. > > If it comes later, back-bdb's custom monitor stuff ends up in the limbo, > which is then flushed when the monitor database starts up. At this > point, a failure in flushing the limbo is not considered critical. > > I see two/three solutions: > > 1) allow databases to fail monitor info registration without aborting > > 2) make startup fail also when limbo flushing fails > > 3) let the monitor database have a default rootdn. > > I'm not oriented towards any of the above, yet. I think the point is: if one explicitly requests monitoring support (by default on) in back-bdb, then it must either succeed or slapd should not start. If one does not explicitly request it, giving up monitoring with a warning should be fine. This is complicated by the need to support run-time configuration: in fact, if monitoring is explicitly requested but it cannot be registered, the creation of that database should fail, but the daemon should not stop. 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#4943) tpool.c pause vs. finish
by hyc＠symas.com 08 Jun '07

08 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > OK, here's where we stand now, with my TODOs, questions and some > new issues. 3+ pages. I thought this would be a brief message:-( > Hopefully I'll get to some of it this weekend, but no promises. > > > TODOs (unless someone protests) and questions: > > * When a thread is finishing, make it go active for context_reset(). > Should make slapi module destructors safer, and I don't see that it > can hurt. I don't understand this. > * I'd like to rename thread contexts to tasks(?) and user contexts back > to contexts (as in RE23). The current terminology is confusing. I don't care about this either way. > > * Save and restore the old data for key slap_sasl_bind, and just in case > (I can't tell if it is needed) smbk5pwd. > > Might as well do it everywhere we have setkey - do something - delete > key in one function call. Since setkey(non-null) isn't supposed to > overwrite existing keys, the change should not be able to hurt. It > could protect something I didn't think of or a future slapd change. > > API: the smallest change would be to call pool_getkey() first, > but I prefer a pool_swapkey(ctx, key, &data, &kfree) function. > Then in RE24, maybe remove the &kfree parameter to pool_getkey(). > > Could omit the &kfree parameter to swapkey() if new data was > guaranteed non-NULL, but that'd require a malloc in bdb (silly says > Howard) or passing data in a &union{integer, ptr} (cumbersome say I). Never use malloc unless absolutely necessary. We have enough problems with heap fragmentation already. > * Axe semaphore code in tpool.c, the ldap_lazy_sem_init() call in > slapd/daemon.c, and with them LDAP_PVT_THREAD_POOL_SEM_LOAD_CONTROL > in ldap_pvt_thread.h and SLAP_SEM_LOAD_CONTROL in slap.h. OK. > * Is the ldap_pvt_thread_pool_context_reset() call in slapd/init.c > indeed safe - ie. its slap_sl_mem_destroy() call? That's not during > startup, but in slap_destroy(). Slapd does various stuff after that. Yes. > * API changes: > > Do we include the assert(no multiple pools) in the import to RE23? > Remove keys from ltu_key[] _before_ calling ltk_free() with them? > That prevents functions called from ltk_free from seeing freed thread > data, but it can also break ltk_free functions that call such > functions _before_ freeing it. Probably not for RE23. > > * Scheduling: If several threads call pool_pause(), then once there is a > pause tpool does not schedule them all. They could get handled then, > or another thread could undo the pause so tpool would wait to pause > again. Is that deliberate? I don't understand the question. The point of the pause is to prevent any other thread (in the pool) from running. Why should tpool schedule any other threads at this point? > Dubious code, new issues, old ones I'm not sure we finished with: > > * thread_keys[] still has problems. > > - pool_context() breaks if several ldap_pvt_thread_t bit patterns can > represent the same thread ID: TID_HASH() would give different hashes > for the same thread, and pool_context() stops searching when it hits > a slot with ctx == NULL. (My previous bug report was a bit wrong.) How can a single thread ID be represented by multiple bit patterns? > The best fix would be to use use real thread-specific data instead. > Just one key with the ctx for now, that minimizes the changes. OTOH > it also means we'll do thread-specific key lookup twice - first in > pthread to get the ctx, and then in ltu_key[] to find our data. > Anyway, I said I'd do that later but might as well get on with it, > at least for pthreads. Except I don't know if that's OS-dependent > enough that it should wait for RE24? The best fix may be to just use the address of the thread's stack as the thread ID. That's actually perfect for our purpose. > When that's not implemented, I'd prefer to cast the thread ID to an > integer when that is safe, and hash that instead of its bytes. > Won't work for structs/unions, and is not formally guaranteed for > pointers or in case of pthreads even integers. BTW, when it doesn't > work, we've got a problem in ITS#4983 (tls.c id_callback) as well. > > When that's not possible, we could search the entire table before > giving up. Could make thread_keys[] smaller and reduce the maximum > allowed #threads on such hosts. (What should the limit be?) > > - thread_keys is a poor hash table implementation with a poor hash > function. Ideally it would not be a hash table at all, but a direct lookup based on the thread ID. > Oops - for caching, maybe I shouldn't have removed the thread id > from thread_keys[]. Or maybe the hash value should be stored there > instead, so we can compare with == instead of ldap_pvt_thread_equal. > > * I wonder if there are long-lived ldap_pvt_thread_cond_wait(), > [r]mutex_lock() or rdwr_[rw]lock() calls which should make the thread > go inactive first (after waiting for any pause to finish), so that > (a) a pool_pause() will not block waiting for them, and > (b) all threads in the pool can't be blocked in long waits without > tpool knowing about it. Long-lived lock calls would be a quite noticeable bug. This seems to be a non-issue. > * back-bdb/tools.c uses pool_submit() to start long-lived threads: > bdb_tool_trickle_task() and bdb_tool_index_task(). They don't exit > until slapd is stopping, so they'll block slapd if a thread requests > a pause. Also the pool thinks its has more available threads that it > does, so scheduled tasks might never be executed. > > Possibly that's not a problem with slaptools. As complex as slapd is > now with overlays and plugins and whatnot, I have no idea. Tool threads are completely separate from slapd threads. This is not an issue. > * slapd/bconfig.c maintains its own idea of the max number of threads > in connection_pool_max and slap_tool_thread_max, which does not match > tpool's idea if the limit is <=0 or larger than LDAP_MAXTHR. > > Since slapd acts on its own count, I imagine that can cause breakage. > Simplest fix might be to set max #threads and then read it back, > I haven't checked. Would need to return LDAP_MAXTHR instead of 0 > for "as many as allowed". Note however also the issue above: > tpool's idea of actually available threads can be too high too. The practical limits are actually pretty low. Even if you're on a 1024 processor machine with many terabytes of RAM, it's not a good idea to have many thousands of threads... Scheduler overhead would overshadow any useful work. > * I said my new ltp_pause waits might be too aggressive. Maybe I should > clarify: I don't see any instances where they can be dropped, but it's > possible that slapd expects pauses to be less aggressive somewhere. I don't understand this comment. > > About pool_submit() and the ltp_mutex unlock-relock: > > Some history and notes, just to finish up previous discussion. > Some possible TODOs, but they are not needed since it's not broken: > > Originally, pool_submit() unlocked ltp_mutex before thread_create() > and re-locked it afterwards for further maintenance. That was not > because of the semaphore code. It looks like it could work even in > non-threaded mode where thread_create(,,fn,arg) just called fn(arg), > though tpool.c was always wrapped in an #ifndef <--without-threads>. > > I don't think non-threaded would have worked anyway since rev 1.24 > (apr 2003), which introduced thread_keys[]. Caller and callee would > have gotten the same thread ID, so tpool would have confused their > contexts. Previously the new context was pushed onto ltp_active_list, > and would have temporarily hid the old context. > > That's also when thread_create() was moved after the ltp_mutex > re-lock, which would mean the mutex was locked while pool_wrapper() > was running and tried to re-lock the mutex. And now, my rev.171 has > removed the unlock-relock. > > With that I can also remove the search for ctx in ltp_pending_list > when backing out of pool_submit, it will be at the head of that list. > > With tpool only supporting threaded mode, another cleanup could be for > pool_submit to start a thread before inserting ctx in ltp_pending_list > instead of after. That done, it can fail if ltp_open_count is still > 0, and we won't need the code for backing out of pool_submit(). OK. > Oh, the comment /* no open threads at all?!? */: That's not strange. > Happens in the first pool_submit() call(s) if thread_create() fails. > Though in that case there was no danger of removing the wrong ctx > from ltp_pending_list after all (fixed in rev 1.63). (Sure, but thread_create() should never fail if you have a sane configuration.) -- -- 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 08 Jun '07

08 Jun '07

OK, here's where we stand now, with my TODOs, questions and some new issues. 3+ pages. I thought this would be a brief message:-( Hopefully I'll get to some of it this weekend, but no promises. TODOs (unless someone protests) and questions: * When a thread is finishing, make it go active for context_reset(). Should make slapi module destructors safer, and I don't see that it can hurt. * I'd like to rename thread contexts to tasks(?) and user contexts back to contexts (as in RE23). The current terminology is confusing. * Save and restore the old data for key slap_sasl_bind, and just in case (I can't tell if it is needed) smbk5pwd. Might as well do it everywhere we have setkey - do something - delete key in one function call. Since setkey(non-null) isn't supposed to overwrite existing keys, the change should not be able to hurt. It could protect something I didn't think of or a future slapd change. API: the smallest change would be to call pool_getkey() first, but I prefer a pool_swapkey(ctx, key, &data, &kfree) function. Then in RE24, maybe remove the &kfree parameter to pool_getkey(). Could omit the &kfree parameter to swapkey() if new data was guaranteed non-NULL, but that'd require a malloc in bdb (silly says Howard) or passing data in a &union{integer, ptr} (cumbersome say I). * Axe semaphore code in tpool.c, the ldap_lazy_sem_init() call in slapd/daemon.c, and with them LDAP_PVT_THREAD_POOL_SEM_LOAD_CONTROL in ldap_pvt_thread.h and SLAP_SEM_LOAD_CONTROL in slap.h. * Is the ldap_pvt_thread_pool_context_reset() call in slapd/init.c indeed safe - ie. its slap_sl_mem_destroy() call? That's not during startup, but in slap_destroy(). Slapd does various stuff after that. * API changes: Do we include the assert(no multiple pools) in the import to RE23? Remove keys from ltu_key[] _before_ calling ltk_free() with them? That prevents functions called from ltk_free from seeing freed thread data, but it can also break ltk_free functions that call such functions _before_ freeing it. Probably not for RE23. * Scheduling: If several threads call pool_pause(), then once there is a pause tpool does not schedule them all. They could get handled then, or another thread could undo the pause so tpool would wait to pause again. Is that deliberate? Dubious code, new issues, old ones I'm not sure we finished with: * thread_keys[] still has problems. - pool_context() breaks if several ldap_pvt_thread_t bit patterns can represent the same thread ID: TID_HASH() would give different hashes for the same thread, and pool_context() stops searching when it hits a slot with ctx == NULL. (My previous bug report was a bit wrong.) The best fix would be to use use real thread-specific data instead. Just one key with the ctx for now, that minimizes the changes. OTOH it also means we'll do thread-specific key lookup twice - first in pthread to get the ctx, and then in ltu_key[] to find our data. Anyway, I said I'd do that later but might as well get on with it, at least for pthreads. Except I don't know if that's OS-dependent enough that it should wait for RE24? When that's not implemented, I'd prefer to cast the thread ID to an integer when that is safe, and hash that instead of its bytes. Won't work for structs/unions, and is not formally guaranteed for pointers or in case of pthreads even integers. BTW, when it doesn't work, we've got a problem in ITS#4983 (tls.c id_callback) as well. When that's not possible, we could search the entire table before giving up. Could make thread_keys[] smaller and reduce the maximum allowed #threads on such hosts. (What should the limit be?) - thread_keys is a poor hash table implementation with a poor hash function. For the hash function, I'll insert a variant of Paul Hsieh's SuperFastHash() instead, or something simpler if we hash an integer. For the hash table, the real fix would be to grab a proper hash table implementation and use that. We might find use for it elsewhere too. Though simple fixes will handle all but some rare cases, and I don't know how much we care: The table is never resized and will slow down lookup when it gets full. A quick fix would be to allow max (70% table size) threads or something. And double the size of the table, if we still want to allow 1024 threads. However if the admin experiments with ltp_max_count for a while so many threads stop/start/stop/start, the table slowly fills up with DELETED_THREAD_CTX entries. Longer search chains, longer thread ID lookup time. Should happen rarely, but we don't advise against it in the docs either. Do we care, beyond documenting it? If yes, we need a real hash table implementation, or at least to re-hash the table when there are too many DELETED_THREAD_CTX entries. Or use a chained hash table. No malloc needed, use the thread's stack space. For open addressing, I was thinking quadric probing would be better than linear, but maybe not with a proper hash function. I don't know what that does to cache issues. Oops - for caching, maybe I shouldn't have removed the thread id from thread_keys[]. Or maybe the hash value should be stored there instead, so we can compare with == instead of ldap_pvt_thread_equal. * I wonder if there are long-lived ldap_pvt_thread_cond_wait(), [r]mutex_lock() or rdwr_[rw]lock() calls which should make the thread go inactive first (after waiting for any pause to finish), so that (a) a pool_pause() will not block waiting for them, and (b) all threads in the pool can't be blocked in long waits without tpool knowing about it. * back-bdb/tools.c uses pool_submit() to start long-lived threads: bdb_tool_trickle_task() and bdb_tool_index_task(). They don't exit until slapd is stopping, so they'll block slapd if a thread requests a pause. Also the pool thinks its has more available threads that it does, so scheduled tasks might never be executed. Possibly that's not a problem with slaptools. As complex as slapd is now with overlays and plugins and whatnot, I have no idea. If it's a problem, it is not enough for them to regularly reschedule themselves and exit: They have long-lived waits. See previous issue. * slapd/bconfig.c maintains its own idea of the max number of threads in connection_pool_max and slap_tool_thread_max, which does not match tpool's idea if the limit is <=0 or larger than LDAP_MAXTHR. Since slapd acts on its own count, I imagine that can cause breakage. Simplest fix might be to set max #threads and then read it back, I haven't checked. Would need to return LDAP_MAXTHR instead of 0 for "as many as allowed". Note however also the issue above: tpool's idea of actually available threads can be too high too. * I said my new ltp_pause waits might be too aggressive. Maybe I should clarify: I don't see any instances where they can be dropped, but it's possible that slapd expects pauses to be less aggressive somewhere. About pool_submit() and the ltp_mutex unlock-relock: Some history and notes, just to finish up previous discussion. Some possible TODOs, but they are not needed since it's not broken: Originally, pool_submit() unlocked ltp_mutex before thread_create() and re-locked it afterwards for further maintenance. That was not because of the semaphore code. It looks like it could work even in non-threaded mode where thread_create(,,fn,arg) just called fn(arg), though tpool.c was always wrapped in an #ifndef <--without-threads>. I don't think non-threaded would have worked anyway since rev 1.24 (apr 2003), which introduced thread_keys[]. Caller and callee would have gotten the same thread ID, so tpool would have confused their contexts. Previously the new context was pushed onto ltp_active_list, and would have temporarily hid the old context. That's also when thread_create() was moved after the ltp_mutex re-lock, which would mean the mutex was locked while pool_wrapper() was running and tried to re-lock the mutex. And now, my rev.171 has removed the unlock-relock. With that I can also remove the search for ctx in ltp_pending_list when backing out of pool_submit, it will be at the head of that list. With tpool only supporting threaded mode, another cleanup could be for pool_submit to start a thread before inserting ctx in ltp_pending_list instead of after. That done, it can fail if ltp_open_count is still 0, and we won't need the code for backing out of pool_submit(). Oh, the comment /* no open threads at all?!? */: That's not strange. Happens in the first pool_submit() call(s) if thread_create() fails. Though in that case there was no danger of removing the wrong ctx from ltp_pending_list after all (fixed in rev 1.63). -- Regards, Hallvard

1 0

Re: (ITS#5005) test017 fails
by quanah＠zimbra.com 08 Jun '07

08 Jun '07

--On June 8, 2007 6:43:50 PM +0000 dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.196.121) > > > here the output of test017 logfiles > > ---slapd.1.log---------------- > ber_scanf fmt (}) ber: > <= get_ctrls: n=1 rc=2 err="Sync control : cookie parsing error" > send_ldap_result: conn=7 op=1 p=3 > send_ldap_result: err=2 matched="" text="Sync control : cookie parsing > error" send_ldap_response: msgid=2 tag=101 err=2 Hm, is this possibly related to the fix for ITS#4977? If you revert that checkin for syncprov.c today, does the test pass? <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c.…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5005) test017 fails
by dieter＠dkluenter.de 08 Jun '07

08 Jun '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.196.121) here the output of test017 logfiles ---slapd.1.log---------------- >>> slap_listener(ldap://localhost:9011/) conn=7 fd=13 ACCEPT from IP=127.0.0.1:13352 (IP=127.0.0.1:9011) connection_get(13) connection_get(13): got connid=7 connection_read(13): checking for input on id=7 ber_get_next ber_get_next: tag 0x30 len 46 contents: ber_get_next do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=manager,dc=example,dc=com> => ldap_bv2dn(cn=manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> do_bind: version=3 dn="cn=manager,dc=example,dc=com" method=128 conn=7 op=0 BIND dn="cn=manager,dc=example,dc=com" method=128 ==> bdb_bind: dn: cn=manager,dc=example,dc=com conn=7 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 do_bind: v3 bind: "cn=manager,dc=example,dc=com" to "cn=Manager,dc=example,dc=com" send_ldap_result: conn=7 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 13 conn=7 op=0 RESULT tag=97 err=0 text= connection_get(13) connection_get(13): got connid=7 connection_read(13): checking for input on id=7 ber_get_next ber_get_next: tag 0x30 len 109 contents: ber_get_next do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=example,dc=com> => ldap_bv2dn(dc=example,dc=com,0) <= ldap_bv2dn(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=example,dc=com)=0 <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> SRCH "dc=example,dc=com" 2 0 0 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="1.3.6.1.4.1.4203.1.9.1.1" (noncritical) ber_scanf fmt ({i) ber: ber_scanf fmt (m) ber: ber_scanf fmt (b) ber: ber_scanf fmt (}) ber: <= get_ctrls: n=1 rc=2 err="Sync control : cookie parsing error" send_ldap_result: conn=7 op=1 p=3 send_ldap_result: err=2 matched="" text="Sync control : cookie parsing error" send_ldap_response: msgid=2 tag=101 err=2 ber_flush2: 49 bytes to sd 13 conn=7 op=1 SEARCH RESULT tag=101 err=2 nentries=0 text=Sync control : cookie parsing error do_search: get_ctrls failed connection_get(13) connection_get(13): got connid=7 connection_read(13): checking for input on id=7 ber_get_next ber_get_next: tag 0x30 len 5 contents: ber_get_next ber_get_next on fd 13 failed errno=0 (Success) connection_closing: readying conn=7 sd=13 for close connection_close: deferring conn=7 sd=13 do_unbind conn=7 op=2 UNBIND connection_resched: attempting closing conn=7 sd=13 connection_close: conn=7 sd=13 conn=7 fd=13 closed daemon: shutdown requested and initiated. --------------------------------------- ---- slapd.2.log ---------------------- >>> slap_listener(ldap://localhost:9012/) conn=1 fd=13 ACCEPT from IP=127.0.0.1:3877 (IP=127.0.0.1:9012) connection_get(13) connection_get(13): got connid=1 connection_read(13): checking for input on id=1 ber_get_next ber_get_next: tag 0x30 len 46 contents: ber_get_next do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=Manager,dc=example,dc=com> => ldap_bv2dn(cn=Manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=Manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128 conn=1 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 ==> bdb_bind: dn: cn=Manager,dc=example,dc=com bdb_dn2entry("cn=manager,dc=example,dc=com") => bdb_dn2id("dc=example,dc=com") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=1 op=0 p=3 send_ldap_result: err=49 matched="" text="" send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 13 conn=1 op=0 RESULT tag=97 err=49 text= connection_get(13) connection_get(13): got connid=1 connection_read(13): checking for input on id=1 ber_get_next ber_get_next on fd 13 failed errno=0 (Success) connection_closing: readying conn=1 sd=13 for close connection_close: conn=1 sd=13 conn=1 fd=13 closed (connection lost) daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 threads to terminate lt-slapd shutdown: initiated ====> bdb_cache_release_all lt-slapd destroy: freeing system resources. slapd stopped. -------------------------------------------------------- ---test.out--------------- ldap_initialize( ldap://localhost:9012 ) ldap_bind: Invalid credentials (49) ------------------------------ -Dieter

1 0

Re: (ITS#4983) libldap_r/tls.c compile failure
by h.b.furuseth＠usit.uio.no 08 Jun '07

08 Jun '07

h.b.furuseth(a)usit.uio.no writes: >kurt(a)OpenLDAP.org writes: >> tls.c: In function `tls_thread_self': >> tls.c:412: error: invalid operands to binary / >> tls.c:415: warning: comparison between pointer and integer > > Well, that was quick... my tls.c rev 1.154 patch, tls_thread_self(), > deliberately causes that for non-integer thread types. What to do? I found this in ITS#4723, from Howard Chu at 29 Nov 2006: > In the current OpenSSL, the address of errno is tested as well. Since > this is always unique per thread, there's really no need to set the id > callback any more. The problem with just using CRYPTO_set_id_callback > is that it doesn't work on platforms where a thread ID is not an > integer (e.g. OS/390). I don't think CRYPTO_set_idptr_callback was > available in earlier OpenSSL releases. Yet Howard added CRYPTO_set_id_callback to tls.c (rev.144) the next day. Why? Should we wrap CRYPTO_set_id_callback() in #if (OpenSSL is old)? Well, I can think of a way the &errno hack can break: The OS could create a small virtual address space which maps to different physical memory for different threads, and put things like errno there. OpenSSL 0.9.9 will apparently have CRYPTO_set_idptr_callback, so we can use an #ifdef for that. For whatever isn't handled above, my suggestion for now is to keep the failure if ldap_pvt_thread_t is a struct/union or wider than long, and see if anyone still complains. -- Regards, Hallvard

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 08 Jun '07

08 Jun '07

ali.pouya(a)free.fr wrote: > OK Pierangelo; > Now I have an explanation : > If you declare the monitor database AFTER bdb slapd starts well. > But if you decalre monitor BEFORE bdb slapd cannot start. > You can test it. OK, I see. The difference is that if the monitor database comes first, it's already open when the bdb tries to register its custom monitor stuff. So it can barf out when the addition fails because of no enough permissions. If it comes later, back-bdb's custom monitor stuff ends up in the limbo, which is then flushed when the monitor database starts up. At this point, a failure in flushing the limbo is not considered critical. I see two/three solutions: 1) allow databases to fail monitor info registration without aborting 2) make startup fail also when limbo flushing fails 3) let the monitor database have a default rootdn. I'm not oriented towards any of the above, yet. 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#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 08 Jun '07

08 Jun '07

OK Pierangelo; Now I have an explanation : If you declare the monitor database AFTER bdb slapd starts well. But if you decalre monitor BEFORE bdb slapd cannot start. You can test it. Thanks for your help Best regards Ali

1 0

(ITS#5003) issue about upper_needs_cast
by caojunliang＠huawei.com 07 Jun '07

07 Jun '07

Full_Name: Cao Junliang Version: openldap-2.3.35 OS: windows xp URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.21.230.126) Hello, when I set the option upper_needs_cast as Yes.It only takes effect on id_query when adding an entry,but does not take effect on child id query when deleting an entry. I found that in the src file back-sql/init.c line 374 --379 there are not operation about upper cast. I want to know if what I think is right. Cao Junliang

1 0

Re: (ITS#5002) Windows Service: logoff causes shutdown
by hyc＠symas.com 07 Jun '07

07 Jun '07

This bug was fixed several years ago. You should update to a current release. This ITS will be closed. mark.lakes(a)alcatel-lucent.com wrote: > Full_Name: Mark Lakes > Version: 2.1.22 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.206.187.100) > > > Summary: LDAP service stops when user logs off. > > The LDAP server is registered as a Windows Service and works correctly with > SCM. > It is registered as an automatic service so should be running all the time. > When a user logs off from the box, the logoff triggers the service to stop > running. > This happens on WindowsXP and Windows 2003 Server that are configured on a > Domain. > > I have a solution. > The problem is that despite the fact it is a service, it receives an event > called CTRL_LOGOFF_EVENT. Since it is not handling this event, the default > behavior by Windows is to shutdown the service. > Add the following code to the source at an appropriate place(probably somewhere > in ntservice.c) for when it runs as a service: > > /** > This is used to handle CTRL_LOGOFF_EVENT from shutting us down when we are > running as a service. > Return TRUE works. We dont really care what the crtlType is. > */ > BOOL WINAPI > WinSigHANDLER_ROUTINE(DWORD ctrlType) > { > /* > char logstr[256]; > sprintf(logstr, "NTservice: caught signal(%d)\n", ctrlType); > writeStatusLog(logstr); > switch (ctrlType) > { > case CTRL_LOGOFF_EVENT: > ... > default: > > } */ > return TRUE; > } > > Then, register the above function in the appropriate place as follows: > SetConsoleCtrlHandler(WinSigHANDLER_ROUTINE, TRUE); > > > > -- -- 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#5002) Windows Service: logoff causes shutdown
by mark.lakes＠alcatel-lucent.com 07 Jun '07

07 Jun '07

Full_Name: Mark Lakes Version: 2.1.22 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.206.187.100) Summary: LDAP service stops when user logs off. The LDAP server is registered as a Windows Service and works correctly with SCM. It is registered as an automatic service so should be running all the time. When a user logs off from the box, the logoff triggers the service to stop running. This happens on WindowsXP and Windows 2003 Server that are configured on a Domain. I have a solution. The problem is that despite the fact it is a service, it receives an event called CTRL_LOGOFF_EVENT. Since it is not handling this event, the default behavior by Windows is to shutdown the service. Add the following code to the source at an appropriate place(probably somewhere in ntservice.c) for when it runs as a service: /** This is used to handle CTRL_LOGOFF_EVENT from shutting us down when we are running as a service. Return TRUE works. We dont really care what the crtlType is. */ BOOL WINAPI WinSigHANDLER_ROUTINE(DWORD ctrlType) { /* char logstr[256]; sprintf(logstr, "NTservice: caught signal(%d)\n", ctrlType); writeStatusLog(logstr); switch (ctrlType) { case CTRL_LOGOFF_EVENT: ... default: } */ return TRUE; } Then, register the above function in the appropriate place as follows: SetConsoleCtrlHandler(WinSigHANDLER_ROUTINE, TRUE);

1 0

(ITS#5001) Incorrect SSF display
by quanah＠OpenLDAP.org 07 Jun '07

07 Jun '07

Full_Name: Quanah Gibson-Mount Version: 2.3.35 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) I was playing with SASL connections on an TLS encrypted connection, and noticed the SSF displayed is not correct in the SASL part. Jun 7 12:51:27 ldap-dev1 slapd[11858]: conn=4494 fd=29 TLS established tls_ssf=256 ssf=256 Jun 7 12:51:27 ldap-dev1 slapd[11858]: conn=4494 op=4 BIND dn="uid=quanah,cn=accounts,dc=stanford,dc=edu" mech=GSSAPI ssf=56 I believe that the second line above should really display "sasl_ssf=56", or probably even better, "sasl_ssf=56 ssf=256", similar to how the first line has "tls_ssf=256 ssf=256", so that it is clear that there are different security factors in play here. --Quanah

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 07 Jun '07

07 Jun '07

HEAD as of now: <slapd.conf> # ... access to * by * none database bdb suffix "dc=example,dc=com" directory /home/masarati/Lavoro/sysnet/Ldap/ldap-devel/tests/testrun/db.1.a rootdn "cn=Manager,dc=example,dc=com" rootpw secret index objectClass eq index cn,sn,uid pres,eq,sub database monitor </slapd.conf> $ slapd -d stats @(#) $OpenLDAP: slapd 2.X (Jun 7 2007 17:39:58) $ masarati@mbdyn-pm:/home/masarati/Lavoro/sysnet/Ldap/ldap-devel/servers/slapd bdb_db_open: Warning - No DB_CONFIG file found in directory /home/masarati/Lavoro/sysnet/Ldap/ldap-devel/tests/testrun/db.1.a: (2) Expect poor performance for suffix dc=example,dc=com. monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=dc=example,dc=com)": unable to find entry slapd starting It seems fine to me. Are you sure there isn't anything else? You might be disguised by a warning that has nothing to do with your real issue. Or, you're not posting enough info. p. ali.pouya(a)free.fr wrote: > Hi Pierangelo; > Unfortunately I reproduced the problem with the HEAD dated June 5. > If I do not add a rootdn to the monitor database, slapd cannot start. > At the end of the log I find : > > monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one > filter="(namingContexts:distinguishedNameMatch:=c=fr)": unable to find entry > > ====> bdb_cache_release_all > backend_startup_one: bi_db_open failed! (-1) > slapd shutdown: initiated > ====> bdb_cache_release_all > bdb_db_close: alock_close failed > slapd destroy: freeing system resources. > slapd stopped. > connections_destroy: nothing to destroy. > > Is the rootdn mandatory for monitor ? > Best Regards > Ali > > > > 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#5000) slapd with invalid url causes crashes
by hyc＠symas.com 07 Jun '07

07 Jun '07

This is most likely the same as ITS#4957 which has already been fixed in the new release candidate. This ITS will be closed. jl+openldap(a)lists.wasmer.ca wrote: > Full_Name: Jean-Luc Wasmer > Version: 2.3.32 > OS: NetBSD 4.0 Beta2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (70.50.240.203) > > > > When slapd is started with an invalid url, it looks like it's trying to destroy > an uninitialized mutex: > > Program received signal SIGABRT, Aborted. > 0xbb87dfff in kill () from /usr/lib/libc.so.12 > (gdb) backtrace > #0 0xbb87dfff in kill () from /usr/lib/libc.so.12 > #1 0xbb94adb3 in pthread__errorfunc () from /usr/lib/libpthread.so.0 > #2 0xbb9491fe in pthread_mutex_destroy () from /usr/lib/libpthread.so.0 > #3 0xbbbbd1eb in ldap_pvt_thread_mutex_destroy () from > /usr/pkg/lib/libldap_r-2.3.so.0 > #4 0x0805a756 in ?? () > #5 0x0819e4fc in __ps_strings () > #6 0x00000002 in ?? () > #7 0xbfbfe8e8 in ?? () > #8 0x0805a713 in ?? () > #9 0x00000286 in ?? () > #10 0x00000001 in ?? () > #11 0xbfbfe958 in ?? () > #12 0x0804e2c1 in ?? () > #13 0xbfa00000 in ?? () > #14 0xbb92cdd0 in tzname () from /usr/lib/libc.so.12 > #15 0x00000002 in ?? () > #16 0x00000000 in ?? () > > Invalid argument that triggered the bug: > -h 'ldap://127.0.0.1 ldaps://<external ip>' > with no interfaces on the system configured with <external ip> > > > . > -- -- 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#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 07 Jun '07

07 Jun '07

Hi Pierangelo; Unfortunately I reproduced the problem with the HEAD dated June 5. If I do not add a rootdn to the monitor database, slapd cannot start. At the end of the log I find : monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=c=fr)": unable to find entry ====> bdb_cache_release_all backend_startup_one: bi_db_open failed! (-1) slapd shutdown: initiated ====> bdb_cache_release_all bdb_db_close: alock_close failed slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. Is the rootdn mandatory for monitor ? Best Regards Ali

1 0

(ITS#5000) slapd with invalid url causes crashes
by jl+openldap＠lists.wasmer.ca 06 Jun '07

06 Jun '07

Full_Name: Jean-Luc Wasmer Version: 2.3.32 OS: NetBSD 4.0 Beta2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.50.240.203) When slapd is started with an invalid url, it looks like it's trying to destroy an uninitialized mutex: Program received signal SIGABRT, Aborted. 0xbb87dfff in kill () from /usr/lib/libc.so.12 (gdb) backtrace #0 0xbb87dfff in kill () from /usr/lib/libc.so.12 #1 0xbb94adb3 in pthread__errorfunc () from /usr/lib/libpthread.so.0 #2 0xbb9491fe in pthread_mutex_destroy () from /usr/lib/libpthread.so.0 #3 0xbbbbd1eb in ldap_pvt_thread_mutex_destroy () from /usr/pkg/lib/libldap_r-2.3.so.0 #4 0x0805a756 in ?? () #5 0x0819e4fc in __ps_strings () #6 0x00000002 in ?? () #7 0xbfbfe8e8 in ?? () #8 0x0805a713 in ?? () #9 0x00000286 in ?? () #10 0x00000001 in ?? () #11 0xbfbfe958 in ?? () #12 0x0804e2c1 in ?? () #13 0xbfa00000 in ?? () #14 0xbb92cdd0 in tzname () from /usr/lib/libc.so.12 #15 0x00000002 in ?? () #16 0x00000000 in ?? () Invalid argument that triggered the bug: -h 'ldap://127.0.0.1 ldaps://<external ip>' with no interfaces on the system configured with <external ip>

1 0

(ITS#4999) Dead Link
by ghenry＠OpenLDAP.org 06 Jun '07

06 Jun '07

Full_Name: Gavin Henry Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dead link: http://www.openldap.org/project/software/repo.html Thanks, Gavin.

1 0

Re: (ITS#4998) overlays/ppolicy.c: invalid pointer due to free() of unallocated buffer
by msl＠calivia.com 04 Jun '07

04 Jun '07

Howard Chu wrote: > msl(a)calivia.com wrote: >> Full_Name: Michael Steinmann >> Version: 2.3.35 / HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.254.173.218) >> >> >> This is while testing a custom pwdCheckModule. >> In function check_password_quality(), char *txt is free()'d, slapd >> crashes with >> "invalid pointer". > > The code works as designed (and as documented). Re-read the > slapo-ppolicy(5) manpage. This ITS will be closed. Got it, thanks. Sorry for the noise. -- mike

1 0

Re: (ITS#4629) slapd failure on HP-UX 11.23/IA 64-bit
by h.b.furuseth＠usit.uio.no 04 Jun '07

04 Jun '07

I've been looking rather belatedly at this patch... it's simple, but the type name ACCEPT_TYPE_ARG3 is a bit ugly to use in .c source files instead of socklen_t. What's the "nice" way to do this? It's an internal type dependent on compiler switches (-D_XOPEN_SOURCE_EXTENDED on HP-UX), so I don't think it is wise to expose it in lber_types.h. It depends on <sys/socket.h> anyway. If not... just use ACCEPT_TYPE_ARG3 or maybe AC_SOCKLEN_T directly in .c files? #define AC_SOCKLEN_T in portable.h and typedef ac_socklen_t as it in sys/socket.h? Cheat and #define ber_socklen_t in portable.h? Also the patch is incomplete, we need to use this type (or some configured type) in getpeername(), getsockopt() and recvfrom() too. I _hope_ they all use the same type or at least a type with the same size on all these platforms... Googling around a bit, the mess with socklen_t and accept() prototypes seems amazing. I'm not sure I dare commit a patch which fails if it doesn't figure out the right type. At least not to RE23 - I'll commit a patch there which just guesses socklen_t or int if it can't figure out the right prototype. We can try one which fails in that case in HEAD and see if anyone complain. If we are going to be as paranoid as some other code out there, it'd be something like this (and even more if we want to try until succeeding in HEAD) - that's 12 compiles instead of the 5 in the submitted patch. Quite a lot... dnl socklen_t-like type in accept(), default socklen_t or int: dnl - The OS might define socklen_t without using it. POSIX moved from dnl int to size_t to socklen_t, hoping to stay at a 32-bit type, and dnl HP-UX has selectors for what to use. dnl - On Solaris 2.8 the prototype has void *len, but the default is OK. AC_MSG_CHECKING([for socklen_t-like type in accept()]) AC_CACHE_VAL(ol_cv_type_lber_socklen_t, [ set socklen_t int unsigned "unsigned long" long size_t test "$ac_cv_type_socklen_t" = yes || shift ol_cv_type_lber_socklen_t=$1 guessing="guessing " for lentype in "$@" ; do for addrtype in "struct sockaddr" void ; do AC_COMPILE_IFELSE([AC_LANG_PROGRAM([$ac_includes_default #ifdef HAVE_SYS_SOCKET_H #include <sys/socket.h> #endif extern int accept(int s, $addrtype *ap, $lentype *lp); ], [ $lentype len; accept(0, (struct sockaddr *) 0, &len); ])], [ol_cv_type_lber_socklen_t=$lentype guessing= ; break 2]) done ; done]) AC_MSG_RESULT([$guessing$ol_cv_type_lber_socklen_t]) AC_DEFINE_UNQUOTED(LBER_SOCKLEN_T, $ol_cv_type_lber_socklen_t, [define to socklen_t-like type in accept()]) -- Regards, Hallvard

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 04 Jun '07

04 Jun '07

ali.pouya(a)free.fr wrote: > Hi Pierangelo; > As you requested, you find below my simplified slapd.conf. > If I comment the line "access to dn.sub="cn=monitor" by * read", then slapd > cannot start. HEAD is working as expected (slapd starts, although it cannot register the database specific monitor info). If a rootdn is added to the monitor database, it starts just fine. What version are you testing? Since this is a > 2.3 specific feature, anything earlier than HEAD will not be considered. 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#4998) overlays/ppolicy.c: invalid pointer due to free() of unallocated buffer
by h.b.furuseth＠usit.uio.no 04 Jun '07

04 Jun '07

hyc(a)symas.com writes: >> This is while testing a custom pwdCheckModule. >> In function check_password_quality(), char *txt is free()'d, slapd >> crashes with "invalid pointer". > > The code works as designed (and as documented). Re-read the > slapo-ppolicy(5) manpage. This ITS will be closed. Actually I think it has a doc bug anyway. See ITS#4901: memory malloced in one Windows DLL must be freed by the same DLL. So the manpage needs to specify _which_ allocation function to use: either ber_memalloc() or slap_sl_malloc(). Because proto-slap.h #defines free to ch_free, which uses ber_memfree_x() or slap_sl_free(). -- Regards, Hallvard

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 04 Jun '07

04 Jun '07

Hi Pierangelo; As you requested, you find below my simplified slapd.conf. If I comment the line "access to dn.sub="cn=monitor" by * read", then slapd cannot start. Best regards Ali ==================================================== include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/ppolicy.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args access to attrs=userPassword by anonymous auth by * none access to dn.sub="cn=monitor" by * read access to * by * none database monitor database bdb serverID 1 suffix "c=fr" rootdn cn=admin,ou=internal,o=gouv,c=fr rootpw {SSHA}1QuNDW3pqQDP93tMcyXo6ClZBJ2VP5XG directory /produits/bdb/data checkpoint 1000000 10 index objectClass,entryCSN,entryUUID eq index uid,cn eq,sub,pres overlay syncprov syncprov-checkpoint 1000 10 syncprov-sessionlog 1000 syncprov-reloadhint TRUE overlay ppolicy ppolicy_hash_cleartext

1 0

Re: (ITS#4998) overlays/ppolicy.c: invalid pointer due to free() of unallocated buffer
by hyc＠symas.com 03 Jun '07

03 Jun '07

msl(a)calivia.com wrote: > Full_Name: Michael Steinmann > Version: 2.3.35 / HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.254.173.218) > > > This is while testing a custom pwdCheckModule. > In function check_password_quality(), char *txt is free()'d, slapd crashes with > "invalid pointer". The code works as designed (and as documented). Re-read the slapo-ppolicy(5) manpage. This ITS will be closed. -- -- 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#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de 03 Jun '07

03 Jun '07

Hello... ando(a)sys-net.it wrote: > You pointed out a misalignment between documentation and code, which > was the result of a continuous evolution of both in an attempt to > make dynlist as general as possible while letting it keep > contradictory configurations under control. The checks currently > implemented resulted too strict, so I relaxed them. Maybe they are > now too relaxed (you just get a warning if you do something odd, but > then the oddest thing you could do would result at most in slowing > down the DSA you admin). Please check if the current code satisfies > your requirements so that the change can be released ASAP. I checked out CVS "HEAD" code, if that is, what cvs -z3 co -P openldap with CVSROOT=:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP does, configured and built it. I might have used a slightly different configuration than my current production environment, but after building I was able to run slapd without even a warning about the following configuration: overlay dynlist dynlist-attrset posixGroup memberURL dynlist-attrset groupOfURLs memberURL owner So, the relaxation of the config checking seems to be successful. Thanks for your fast reaction to my issue report. bye Christian -- Christian Marg mail: mailto:marg@rz.tu-clausthal.de Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : <on request>

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by ando＠sys-net.it 03 Jun '07

03 Jun '07

I think you need to realize that dynlist (and dynamic groups in general) represent an abuse of the LDAP data model. You pointed out a misalignment between documentation and code, which was the result of a continuous evolution of both in an attempt to make dynlist as general as possible while letting it keep contradictory configurations under control. The checks currently implemented resulted too strict, so I relaxed them. Maybe they are now too relaxed (you just get a warning if you do something odd, but then the oddest thing you could do would result at most in slowing down the DSA you admin). Please check if the current code satisfies your requirements so that the change can be released ASAP. Don't expect dynlist to do all you want it to do, and exactly as you want it, because it needs to satisfy other requirements as well. If you want to design specs for dynamic groups, or dynamic lists, maybe an ITS is not the right forum. 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#4998) overlays/ppolicy.c: invalid pointer due to free() of unallocated buffer
by msl＠calivia.com 03 Jun '07

03 Jun '07

Full_Name: Michael Steinmann Version: 2.3.35 / HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.254.173.218) This is while testing a custom pwdCheckModule. In function check_password_quality(), char *txt is free()'d, slapd crashes with "invalid pointer". Core was generated by `servers/slapd/slapd -f etc/openldap/slapd.conf -h ldap://localhost:10389/ -d 9'. Program terminated with signal 6, Aborted. #0 0xb7b3a0b6 in raise () from /lib/libc.so.6 (gdb) bt #0 0xb7b3a0b6 in raise () from /lib/libc.so.6 #1 0xb7b3b841 in abort () from /lib/libc.so.6 #2 0xb7b7019b in __libc_message () from /lib/libc.so.6 #3 0xb7b75de2 in malloc_printerr () from /lib/libc.so.6 #4 0x08089bb8 in ch_free (ptr=0xb7c3aff4) at ch_malloc.c:139 #5 0x08119833 in check_password_quality (cred=0x2, pp=<value optimized out>, err=0xb752becc, e=0x8285998) at ppolicy.c:650 #6 0x0811ac59 in ppolicy_modify (op=0x8285028, rs=0xb752c1c4) at ppolicy.c:1751 #7 0x080c7134 in overlay_op_walk (op=0x8285028, rs=0xb752c1c4, which=op_modify, oi=0x822f488, on=0x822f578) at backover.c:498 #8 0x080c758d in over_op_func (op=0x8285028, rs=0xb752c1c4, which=op_modify) at backover.c:560 #9 0x080a117b in passwd_extop (op=0x8285028, rs=0xb752c1c4) at passwd.c:284 #10 0x0809f611 in fe_extended (op=0x8285028, rs=0xb752c1c4) at extended.c:215 #11 0x0809fb79 in do_extended (op=0x8285028, rs=0xb752c1c4) at extended.c:180 #12 0x08070589 in connection_operation (ctx=0xb752c238, arg_v=0x8285028) at connection.c:1133 #13 0x08143ae3 in ldap_int_thread_pool_wrapper (xpool=0x820eb40) at tpool.c:478 #14 0xb7c43f8a in start_thread () from /lib/libpthread.so.0 #15 0xb752c480 in ?? () #16 0xb752c480 in ?? () #17 0xb752c480 in ?? () #18 0xb752c480 in ?? () #19 0x00000000 in ?? () Patch below fixes the issue. Index: ppolicy.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/ppolicy.c,v retrieving revision 1.98 diff -r1.98 ppolicy.c 652d651 < free(txt);

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de 03 Jun '07

03 Jun '07

Hello Kurt, Kurt Zeilenga wrote: > On Jun 2, 2007, at 2:47 PM, marg(a)rz.tu-clausthal.de wrote: [...] >> posixGroup and groupOfURLs are both "structural" objectclasses so >> an entry is either a "groupofURL" or a "posixGroup", never both. > > Yes, but an entry can belong to both. That is, an entry's structural > class could inherit from both of these classes. I didn't know that multiple inheritance existed in an LDAP schema. Or did you mean that there is an inheritance chain like: "top - person - organisationalPerson - inetOrgPerson"? In the latter case - if dynlist honored inheritance - the rules should be made clear: 1st example: dynlist-attrset person personURL dynlist-attrset inetOrgPerson inetOrgPersonURL No problem: An inetOrgPerson-Object is encountered and if both *URL-Attributes were defined, both would be expanded. 2nd example: dynlist-attrset person someURL dynlist-attrset inetOrgPerson someURL In this case there would have to be rule for matching: Either first-match or most exact match. >> And in this case the memberURL can have different meanings >> according to the Objectclass it is used in. > > That's called bad schema design. If an attribute has is specified to > have different meaning when used with X then when used with Y, it's > not only unclear what meaning the attribute as when used with both X > and Y, but also used without either X or Y. Ok, I was beeing unclear: memberURL of course has no different meaning in two different group type OCs - it is the URL that lists the members of that group. Only difference is that OC 'A' might not allow attribute 'S' returned by the LDAP URL used for expansion in OC 'B', while OC 'B' might not allow attribute 'T' returned by the LDAP URL used for expansion in OC 'A'. Still both LDAP URLs are values of the Attribute "memberURL". And no schema constraint I know of can control what an LDAP URL specifies. I could add multiple Attribute-Descriptions (SUP labeledURI) like: uidexpansionURL - containing only LDAP URLS like ldap:///<base>?uid?<scope>?<filter> mailexpansionURL - containing only LDAP URLS like ldap:///<base>?mail?<scope>?<filter> but now I've got two different objectclasses that should list a set of mail adresses - what should I do? Should I really define two attributes OCAmailexpansionURL and OCBmailexpansionURL just to satisfy current(?) dynlist configuration rules? I think that would be bad schema design: Different attributes for values meaning the same. > Note that attributes may be added to an entry which are not allowed > by any of the classes the entry belongs to... (see DIT content > rules). The addition of the "extensibleObject" OC is the closest thing I've seen to what I understand from that sentence. I just don't understand what this has to do with Pierangelo believing that expansion of the same URL attribute in different object classes should be forbidden. bye Christian -- Christian Marg mail: mailto:marg@rz.tu-clausthal.de Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : <on request>

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by kurt＠OpenLDAP.org 03 Jun '07

03 Jun '07

On Jun 2, 2007, at 2:47 PM, marg(a)rz.tu-clausthal.de wrote: > Hello... > > ando(a)sys-net.it wrote: >> marg(a)rz.tu-clausthal.de wrote: >> >>> I found a behaviour issue with the dynlist overlay configuration: >>> >>> I tried the following configuration: >>> >>> overlay dynlist >>> dynlist-attrset posixGroup memberURL >>> dynlist-attrset groupOfURLs memberURL owner >> >> The reason of that check is that the same attribute "memberURL" could >> otherwise be used by both group classes to expand. > > [...] > >> However, I believe something like >> >> dynlist-attrset posixGroup memberURL >> dynlist-attrset groupOfURLs memberURL >> >> should still be forbiden, otherwise the same "memberURL" would expand >> twice. This, strictly speaking, is not an issue, as duplicates would >> simply be discarded, but it would cause unnecessary overhead. Right >> now, I have decided to turn this check into a config-time warning. > > Hmm - I object. > > posixGroup and groupOfURLs are both "structural" objectclasses so an > entry is either a "groupofURL" or a "posixGroup", never both. Yes, but an entry can belong to both. That is, an entry's structural class could inherit from both of these classes. > And in > this case the memberURL can have different meanings according to the > Objectclass it is used in. That's called bad schema design. If an attribute has is specified to have different meaning when used with X then when used with Y, it's not only unclear what meaning the attribute as when used with both X and Y, but also used without either X or Y. Note that attributes may be added to an entry which are not allowed by any of the classes the entry belongs to... (see DIT content rules). > Otherwise I'd have to create an Attribute for every expansion I > want to > use - that can't be right! > > You are right for expansions in auxillary OCs, of course! They > shouldn't > be using the same attribute... > >> Please test and report. > > Will do, sometime soon. > > bye > Christian > -- > Christian Marg mail: mailto:marg@rz.tu-clausthal.de > Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de > D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 > Germany ICQ : <on request> > >

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de 03 Jun '07

03 Jun '07

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig98A1F9874D1718E82ABEA8E9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello. Pierangelo Masarati wrote: > Christian Marg wrote: >=20 >> Hmm - I object. >> >> posixGroup and groupOfURLs are both "structural" objectclasses so an >> entry is either a "groupofURL" or a "posixGroup", never both. >=20 > OK, my example was stupid. But you got the idea below. >=20 >> You are right for expansions in auxillary OCs, of course! They shouldn= 't >> be using the same attribute... Couldn't the config file check test if the OC is structural/auxilliary? Do you expand for OC InetOrgPerson if an expansion was configured for OC Person? I can configure an expansion for the abstract objectclass "TOP" without any error message (that doesn't really make sense, I know, because they don't exist in the directory) - if you'd respect inheritance that would be a fun thing to do - every Objectclass is (in-)directly inherited from "TOP" ;) bye Christian --=20 Christian Marg mail: mailto:marg@rz.tu-clausthal.de Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : <on request> --------------enig98A1F9874D1718E82ABEA8E9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGYtNyXwu7mUb3ymMRAoO/AJ9vdGCDBj3yGCUYjkOEppngJRWdzACffxB0 WuO/HvOk3KkVUzg5k6VA20g= =Y3xR -----END PGP SIGNATURE----- --------------enig98A1F9874D1718E82ABEA8E9--

1 0

Re: (ITS#4994) Clarify -y option in man pages
by rra＠stanford.edu 02 Jun '07

02 Jun '07

Pierangelo Masarati <ando(a)sys-net.it> writes: > rra(a)stanford.edu wrote: >> A Debian user was confused by the -y option and its inclusion of >> whitespace in the password. The current man page text does explain >> this, but it doesn't make a point of it, and I think a bit more >> explanation would be useful. Here's a patch for the ldapcompare.1 man >> page; if you think this is a good idea, similar changes could be made >> to all the other command-line utilities that take the -y option. > I have committed a different clarification that provides a hint to a > portable manner to generate appropriate password files. Please check > and improve; afterwards I'll apply it to other command line tools man > pages. Perfect, and a substantial improvement over my patch. Thank you! -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4997) lmpasswd support using gcrypt
by rra＠stanford.edu 02 Jun '07

02 Jun '07

Kurt Zeilenga <kurt(a)OpenLDAP.org> writes: > Without involvement from the authors of this patch, it's better to > simply rewrite the feature from scratch. No problem. The patch is conceptually trivial. I'll plan on reimplementing it from scratch unless I can contact the original author (or possibly anyway if it's faster). -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4971)
by ando＠sys-net.it 02 Jun '07

02 Jun '07

jemeterisan(a)mail.ru wrote: > O.k, thanks. But, I would like to know, what does the termin "HEAD > code" mean? the HEAD branch out of the CVS. > And where can I get it? <http://www.openldap.org/software/repo.html#AnonCVS> >> Any blob-like format would be fine (although I haven't tested it >> with PostgreSQL yet). > > So, do You mean BLOB-like format as oid (in PostgreSQL), or just > something like varbit type? I'm not that familiar with variable size binary data in PostgreSQL, but I guess something like "bytea" should work. With MySQL, "LONGBLOB" worked. > I tried to put BLOBs in PostgreSQL by > ldapadd - it's possible. Usually, you need to encode those objects in a way ldapadd can munch. For example, base64 encode them, like binaryAttr:: thisisabase64encodedvalue= or ask it to swallow the file as is, using binaryAttr:< file:///path/to/binary.dat > But I had some problems when I tried to read > from oid. I just had got the value of oid, but not stored data. Not sure I understand what you mean. But here we're getting off-topic with this ITS; please continue discussion, if needed, on the openldap-software mailing list. 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#4971)
by h.b.furuseth＠usit.uio.no 02 Jun '07

02 Jun '07

jemeterisan(a)mail.ru writes: > what does the termin "HEAD code" mean? > And where can I get it? Sorry for my educationless... The source code is stored in a CVS repository, as described here: http://www.openldap.org/software/repo.html The development branch is named HEAD. As the above URL says, you can check it out with % setenv CVSROOT :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP % cvs login Password: (enter OpenLDAP) % cvs -z3 checkout -P ldap % cvs logout -- Regards, Hallvard

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by ando＠sys-net.it 02 Jun '07

02 Jun '07

Christian Marg wrote: > Hmm - I object. > > posixGroup and groupOfURLs are both "structural" objectclasses so an > entry is either a "groupofURL" or a "posixGroup", never both. OK, my example was stupid. But you got the idea below. > And in > this case the memberURL can have different meanings according to the > Objectclass it is used in. > > Otherwise I'd have to create an Attribute for every expansion I want to > use - that can't be right! > > You are right for expansions in auxillary OCs, of course! They shouldn't > be using the same attribute... > >> Please test and report. > > Will do, sometime soon. Thanks, 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#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de 02 Jun '07

02 Jun '07

Hello... ando(a)sys-net.it wrote: > marg(a)rz.tu-clausthal.de wrote: > >> I found a behaviour issue with the dynlist overlay configuration: >> >> I tried the following configuration: >> >> overlay dynlist >> dynlist-attrset posixGroup memberURL >> dynlist-attrset groupOfURLs memberURL owner > > The reason of that check is that the same attribute "memberURL" could > otherwise be used by both group classes to expand. [...] > However, I believe something like > > dynlist-attrset posixGroup memberURL > dynlist-attrset groupOfURLs memberURL > > should still be forbiden, otherwise the same "memberURL" would expand > twice. This, strictly speaking, is not an issue, as duplicates would > simply be discarded, but it would cause unnecessary overhead. Right > now, I have decided to turn this check into a config-time warning. Hmm - I object. posixGroup and groupOfURLs are both "structural" objectclasses so an entry is either a "groupofURL" or a "posixGroup", never both. And in this case the memberURL can have different meanings according to the Objectclass it is used in. Otherwise I'd have to create an Attribute for every expansion I want to use - that can't be right! You are right for expansions in auxillary OCs, of course! They shouldn't be using the same attribute... > Please test and report. Will do, sometime soon. bye Christian -- Christian Marg mail: mailto:marg@rz.tu-clausthal.de Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : <on request>

1 0

(ITS#4971)
by jemeterisan＠mail.ru 02 Jun '07

02 Jun '07

-----Original Message----- From: Pierangelo Masarati <ando(a)sys-net.it> To: jemeterisan(a)mail.ru Date: Fri, 18 May 2007 19:10:03 +0200 Subject: Re: (ITS#4971) patch for OpenLDAP 2-3-32 > I assume you refer to a patch that was submitted along with ITS#4868; > that patch is absolutely incorrect and in fact it has been rejected. A > consistent fix has been applied to hEAD code. It has never been > backported to OpenLDAP 2.3 because nobody fed back about it. If you > wish to test HEAD code and report success, I'll be happy to backport it > to OpenLDAP 2.3 so that it gets released with the next release. > O.k, thanks. But, I would like to know, what does the termin "HEAD code" mean? And where can I get it? Sorry for my educationless... > Any blob-like format would be fine (although I haven't tested it with > PostgreSQL yet). So, do You mean BLOB-like format as oid (in PostgreSQL), or just something like varbit type? I tried to put BLOBs in PostgreSQL by ldapadd - it's possible. But I had some problems when I tried to read from oid. I just had got the value of oid, but not stored data. With best wishes, Dmitry...

1 0

Re: (ITS#4997) lmpasswd support using gcrypt
by kurt＠OpenLDAP.org 02 Jun '07

02 Jun '07

On Jun 2, 2007, at 6:31 AM, rra(a)stanford.edu wrote: > Full_Name: Russ Allbery > Version: 2.4 (HEAD) > OS: Debian > URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245341 > Submission from: (NULL) (171.66.157.14) > > > Now that 2.4 has native GnuTLS support, the patch that's been > sitting around in > Debian bug #245341 becomes potentially interesting (see the > associated URL). > This is a request to support LAN Manager password hashes when > OpenLDAP is built > with GnuTLS instead of OpenSSL, thus requiring using libgcrypt to > do the DES > work instead of OpenSSL's DES library. > > The patch in that bug almost certainly isn't okay in its current form, Note that 3rd party contributions are generally not acceptable (for IPR reasons). That is, we generally require the author(s) of the patch to contribute the patch. If you think this patch is useful, you might suggest to its authors that they contribute it to the Project. In doing so, it's good to provide a link to our contributing guidelines, http://www.openldap.org/devel/ contributing.html. > but I > wanted to get the ITS filed for this feature request so that > there's a record in > the database and just in case someone else feels inspired to bring > the patch up > to date and clean it up. (Unlikely, I know.) Otherwise, I will > probably clean > this patch up for further submission at some point near the 2.4 > release (on > which side of it, I'm not sure). Without involvement from the authors of this patch, it's better to simply rewrite the feature from scratch. -- Kurt

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by ando＠sys-net.it 02 Jun '07

02 Jun '07

richton(a)nbcs.rutgers.edu wrote: Committed. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by ando＠sys-net.it 02 Jun '07

02 Jun '07

marg(a)rz.tu-clausthal.de wrote: > I found a behaviour issue with the dynlist overlay configuration: > > I tried the following configuration: > > overlay dynlist > dynlist-attrset posixGroup memberURL > dynlist-attrset groupOfURLs memberURL owner The reason of that check is that the same attribute "memberURL" could otherwise be used by both group classes to expand. > > but slaptest complains about it - and the slapd doesn't start with it: > > @(#) $OpenLDAP: slapd 2.3.34[...] > /usr/local/etc/openldap/slapd.conf: line 91: "dynlist-attrset <oc> > <URL-ad> [<member-ad>]": URL attributeDescription "memberURL" already > mapped. > slapd stopped. > > When I use multiple "overlay dynlist"-entries like: > > overlay dynlist > dynlist-attrset posixGroup memberURL > overlay dynlist > dynlist-attrset groupOfURLs memberURL owner > > it works as expected, but there is a warning: > > overlay_config(): warning, overlay "dynlist" already in list > > PS: Although the new Version 2.3.35 isn't available via FreeBSD Ports > yet, I don't think that it would change anything, because the source > file of the dynlist-overlay doesn't seem to have changed in any part > that matters to this issue. I think the documentation describes the intended behavior, but configuration parsing is not (no longer?) in agreement with the documentation. I think the real issue is that the behavior is no longer consistent for compares and searches: - for searches, only the first group that matches the entry's objectClass will be expanded - for compares, all groups that match will be expanded until a match is found I'm reworking the configuration test to be consistent with the documentation, and the code to be self-consistent: now all groups matching the entry are expanded. So now a configuration like dynlist-attrset groupOfURLs memberURL dynlist-attrset groupOfURLs memberURL member will simultaneously merge all attributes listed in a "memberURL", and add the expanded entries' DN as "member". However, I believe something like dynlist-attrset posixGroup memberURL dynlist-attrset groupOfURLs memberURL should still be forbiden, otherwise the same "memberURL" would expand twice. This, strictly speaking, is not an issue, as duplicates would simply be discarded, but it would cause unnecessary overhead. Right now, I have decided to turn this check into a config-time warning. Please test and report. 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#4994) Clarify -y option in man pages
by ando＠sys-net.it 02 Jun '07

02 Jun '07

rra(a)stanford.edu wrote: > A Debian user was confused by the -y option and its inclusion of whitespace in > the password. The current man page text does explain this, but it doesn't make > a point of it, and I think a bit more explanation would be useful. Here's a > patch for the ldapcompare.1 man page; if you think this is a good idea, similar > changes could be made to all the other command-line utilities that take the -y > option. I have committed a different clarification that provides a hint to a portable manner to generate appropriate password files. Please check and improve; afterwards I'll apply it to other command line tools man pages. 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#4997) lmpasswd support using gcrypt
by rra＠stanford.edu 01 Jun '07

01 Jun '07

Full_Name: Russ Allbery Version: 2.4 (HEAD) OS: Debian URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245341 Submission from: (NULL) (171.66.157.14) Now that 2.4 has native GnuTLS support, the patch that's been sitting around in Debian bug #245341 becomes potentially interesting (see the associated URL). This is a request to support LAN Manager password hashes when OpenLDAP is built with GnuTLS instead of OpenSSL, thus requiring using libgcrypt to do the DES work instead of OpenSSL's DES library. The patch in that bug almost certainly isn't okay in its current form, but I wanted to get the ITS filed for this feature request so that there's a record in the database and just in case someone else feels inspired to bring the patch up to date and clean it up. (Unlikely, I know.) Otherwise, I will probably clean this patch up for further submission at some point near the 2.4 release (on which side of it, I'm not sure).

1 0

Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by kurt＠OpenLDAP.org 01 Jun '07

01 Jun '07

On Jun 2, 2007, at 5:31 AM, rra(a)stanford.edu wrote: > Full_Name: Russ Allbery > Version: 2.3.35 > OS: Debian > URL: > Submission from: (NULL) (171.66.157.14) > > > A user of the Debian OpenLDAP package requested support in the > command-line > utilities for using SRV entries to locate the local LDAP server. My > understanding of the suggestion is that if one didn't specify -h or > -H, a SRV > record lookup would be tried before falling back to localhost. > (You may not > want to change the default behavior, though, and add another switch.) One could use DNS SRV on the domain provided by -H, or by ldap.conf (5), and use it present, with (likely best) or without an option to enable the behavior. One could also use DNS SRV on the domain associated with the baseObject/target DN with an option to enable this behavior. That is, ldapsearch -b "dc=example,dc=org" would cause a DNS SRV lookup on example.org. This is what the DNSSRV backend does. Not sure adding to the command line tools would be especially useful. That is, I don't think DNS SRV fits well in the common use pattern of command line tools. But someone implements this behind an option, it shouldn't do any harm. Lastly I note that the domain to use DNS SRV should come from the user (or application entity), not the local host. Using the local resolver configuration is a really bad idea. -- Kurt > > For the full suggestion, see: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221173 > > It looks like much of the necessary code is already there in > libldap, and > looking at the libldap code, you could also intuit the correct > server based on > any search base provided. > >

1 0

(ITS#4996) Use SRV records to locate local server for command-line clients
by rra＠stanford.edu 01 Jun '07

01 Jun '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.66.157.14) A user of the Debian OpenLDAP package requested support in the command-line utilities for using SRV entries to locate the local LDAP server. My understanding of the suggestion is that if one didn't specify -h or -H, a SRV record lookup would be tried before falling back to localhost. (You may not want to change the default behavior, though, and add another switch.) For the full suggestion, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221173 It looks like much of the necessary code is already there in libldap, and looking at the libldap code, you could also intuit the correct server based on any search base provided.

1 0

slapd with wrong url causes "Error detected by libpthread: Invalid mutex"
by Jean-Luc Wasmer 01 Jun '07

01 Jun '07

Hi, When slapd is started with an invalid url, it looks like it's trying to destroy an uninitialized mutex: Program received signal SIGABRT, Aborted. 0xbb87dfff in kill () from /usr/lib/libc.so.12 (gdb) backtrace #0 0xbb87dfff in kill () from /usr/lib/libc.so.12 #1 0xbb94adb3 in pthread__errorfunc () from /usr/lib/libpthread.so.0 #2 0xbb9491fe in pthread_mutex_destroy () from /usr/lib/libpthread.so.0 #3 0xbbbbd1eb in ldap_pvt_thread_mutex_destroy () from /usr/pkg/lib/libldap_r-2.3.so.0 #4 0x0805a756 in ?? () #5 0x0819e4fc in __ps_strings () #6 0x00000002 in ?? () #7 0xbfbfe8e8 in ?? () #8 0x0805a713 in ?? () #9 0x00000286 in ?? () #10 0x00000001 in ?? () #11 0xbfbfe958 in ?? () #12 0x0804e2c1 in ?? () #13 0xbfa00000 in ?? () #14 0xbb92cdd0 in tzname () from /usr/lib/libc.so.12 #15 0x00000002 in ?? () #16 0x00000000 in ?? () This was triggered by calling slapd with an invalid URLlist argument: -h 'ldap://127.0.0.1 ldaps://<external ip>' with no interfaces on the system configured with <external ip>

4 6

(ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by rra＠stanford.edu 01 Jun '07

01 Jun '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.66.157.14) While investigating another issue with back_perl, I tried to use the SampleLDAP.pm module that comes with the OpenLDAP source. I added the following to my slapd.conf: moduleload back_perl # ... database perl suffix "o=AnyOrg,c=US" perlModulePath /home/eagle/SampleLDAP.pm perlModule SampleLDAP The result of slapd -d 1 is: ... WARNING: No dynamic config support for database perl. config_build_entry: "olcDatabase={2}perl" backend_startup_one: starting "dc=Stanford,dc=EDU" bdb_db_open: unclean shutdown detected; attempting recovery. bdb_db_open: dbenv_open(/var/lib/ldap) backend_startup_one: starting "o=AnyOrg,c=US" Can't call method "init" on an undefined value. I suspect the code in perl_back_db_open where it does: dSP; ENTER; SAVETMPS; PUSHMARK(sp); XPUSHs( perl_back->pb_obj_ref ); PUTBACK; #ifdef PERL_IS_5_6 count = call_method("init", G_SCALAR); #else count = perl_call_method("init", G_SCALAR); #endif The error message is consistent with perl_back->pb_obj_ref being an undefined value. Why it's undefined, though, I'm not sure. See also http://www.openldap.org/lists/openldap-software/200705/msg00126.html

1 0

(ITS#4994) Clarify -y option in man pages
by rra＠stanford.edu 01 Jun '07

01 Jun '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.64.19.147) A Debian user was confused by the -y option and its inclusion of whitespace in the password. The current man page text does explain this, but it doesn't make a point of it, and I think a bit more explanation would be useful. Here's a patch for the ldapcompare.1 man page; if you think this is a good idea, similar changes could be made to all the other command-line utilities that take the -y option. --- ldapcompare.1 (revision 805) +++ ldapcompare.1 (working copy) @@ -106,8 +106,12 @@ Use \fIpasswd\fP as the password for simple authentication. .TP .BI \-y \ passwdfile -Use complete contents of \fIpasswdfile\fP as the password for -simple authentication. +Use complete contents of \fIpasswdfile\fP, including any leading or +trailing whitespace and any final newlines, as the password for +simple authentication. If the password does not contain a newline, +be careful when creating this file. Many editors and commands like +\fBecho\fP will add a trailing newline, which will then be taken as part +of the password. .TP .BI \-H \ ldapuri Specify URI(s) referring to the ldap server(s); only the protocol/host/port

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 01 Jun '07

01 Jun '07

hyc(a)symas.com writes: >hyc(a)symas.com wrote: >> When we finally get the time to write up a new C API we can worry about >> where to draw the line between the library and slapd code but for now >> it's all (philosophically) private to slapd. > > (And of course, historically it made sense to put it in the library > because it was also used by slurpd. But that reason is no longer > pertinent...) It was? slurpd uses ldap_pvt_thread_create() directly in both RE23 and openldap-2.0.0. Grepping it for pool finds nothing. However it does use libldap_r/threads.c, which starts and stops a pool. Yet another matter, since I'm messing so much with tpool anyway: It's been confusing to have two types of contexts, thread and user contexts. I suggest to rename thread contexts to "tasks". They don't look very contexty to me anyway. As far as I can tell they are not exposed outside tpool.c, so it won't affect anything else. User contexts can be renamed back to plain contexts like in RE23. (The code is confused, too - ldap_int_main_thrctx and my DELETED_THREAD_CTX are user contexts, not thread contexts.) -- Regards, Hallvard

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 01 Jun '07

01 Jun '07

hyc(a)symas.com wrote: > When we finally get the time to write up a new C API we can worry about > where to draw the line between the library and slapd code but for now > it's all (philosophically) private to slapd. (And of course, historically it made sense to put it in the library because it was also used by slurpd. But that reason is no longer pertinent...) -- -- 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#4943) tpool.c pause vs. finish
by hyc＠symas.com 01 Jun '07

01 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >>> tpool.c breaks if there are multiple pools. The simplest >>> solution seems to be to remove support for multiple pools. >>> The problem is thread_keys[]. It is shared between pools, but: >> slapd only uses a single pool, and that's really the only use case we >> care about. In fact it makes no sense to support multiple pools, >> because we have no mechanism to assert scheduling priorities of one >> pool over another. > > I'm afraid I did not think of scheduling priorities at all, only bugs. > But it certainly makes things simpler if we remove multiple pools. > > Simple documentation of how tpool should be used may remove some of > my concerns - or how it _is_ used, since it's only used in slapd. > (Several probably only are problems if it is used as a library feature. > tpool depends on being used the way slapd is using it. I've wondered > what it's doing in libldap_r/ instead of in slapd/.) One thing to remember, which has been discussed before - all of libldap_r exists solely for the benefit of slapd. The only "official" LDAP API is what was defined in the expired C API draft, and that draft never addressed reentrancy issues. Any use of libldap_r outside of slapd is and always will be unsupported; any bugs that might exist solely due to unintended usage are not our concern. When we finally get the time to write up a new C API we can worry about where to draw the line between the library and slapd code but for now it's all (philosophically) private to slapd. -- -- 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#4993) Roadmap very out of date
by bevan＠fulcrummicro.com 31 May '07

31 May '07

Full_Name: Bevan Bennett Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.59.247.209) The roadmap at http://www.openldap.org/software/roadmap.html has not been updated since January of 2006, and lists version 2.4 as being expected in "Q1 of 2006". Since we're now nearly done with Q2 of 2007, this is clearly not the case. Someone should pop in and update the roadmap to reflect the last 16 months of progress or lack thereof.

1 0

(ITS#4992) cldap ber_write assertion fix
by mba2000＠ioplex.com 31 May '07

31 May '07

Full_Name: Michael B Allen Version: 2.3.33 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.142.196.170) ldap_search_ext with cldap:// will assert because it calls ldap_build_search_req which calls ber_write w/ a NULL ld->ld_options.ldo_peer. The following patch defers encoding the address with ber_write until after the ldo_peer is initialized in request.c. Note that cldap functionality is still not optimal. The transport hangs if there is no reply. --- search.c-2007-05-30 2007-05-30 21:20:06.000000000 -0400 +++ search.c 2007-05-30 21:50:45.000000000 -0400 @@ -259,8 +259,9 @@ LDAP_NEXT_MSGID( ld, *idp ); #ifdef LDAP_CONNECTIONLESS if ( LDAP_IS_UDP(ld) ) { - err = ber_write( ber, ld->ld_options.ldo_peer, - sizeof(struct sockaddr), 0); + struct sockaddr sa; + memset(&sa, 0, sizeof sa); + err = ber_write( ber, &sa, sizeof(struct sockaddr), 0); } if ( LDAP_IS_UDP(ld) && ld->ld_options.ldo_version == LDAP_VERSION2) { char *dn = ld->ld_options.ldo_cldapdn; --- request.c-2007-05-30 2007-05-30 21:39:05.000000000 -0400 +++ request.c 2007-05-30 21:54:33.000000000 -0400 @@ -222,6 +222,19 @@ use_connection( ld, lc ); +#ifdef LDAP_CONNECTIONLESS + if ( LDAP_IS_UDP(ld) ) { + BerElement tmp = *ber; + ber_rewind( &tmp ); /* encode addr at start */ + rc = ber_write( &tmp, ld->ld_options.ldo_peer, + sizeof(struct sockaddr), 0); + if ( rc == -1 ) { + ld->ld_errno = LDAP_ENCODING_ERROR; + return( -1 ); + } + } +#endif + /* If we still have an incomplete write, try to finish it before * dealing with the new request. If we don't finish here, return * LDAP_BUSY and let the caller retry later. We only allow a single

1 0

Re: (ITS#4991) pcache and rwm don't play well together
by rhafer＠suse.de 31 May '07

31 May '07

Fix is in rwm.c (r1.85) and pcache.c (r1.105) -- Ralf

1 0

(ITS#4991) pcache and rwm don't play well together
by rhafer＠suse.de 31 May '07

31 May '07

Full_Name: Ralf Haferkamp Version: RE23, HEAD OS: Linux (Kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.181.19) The rwm and pcache overlays don't work very well together on a single database. The main reason for this seems to be that both overlays touch the list of requested Attributes in a search request and are not prepared for the fact that other overlays might touch that list as well. As a result the Entries returned by a Search against such a database can be incomplete and the server crashes because the various AttributeList arrays are free'd multiple times (or in the wrong place). I think I've a fix for HEAD is mostly ready, still testing it. I'll commit it shortly.

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 31 May '07

31 May '07

hyc(a)symas.com wrote: >h.b.furuseth(a)usit.uio.no wrote: >> (...) >> But it would cleaner to ch_malloc an integer instead of the (void*) >> cast. Then it won't depend on integer->pointer->integer conversions >> preserving the value either. > > Ugh. That's just silly. We should just typedef a union that's big enough > to hold a pointer or an integer... Eh? Then we'd need to change every setkey/getkey call to use set/get that union instead of a simple pointer. > (...) >> Was that an instruction/permission to axe it or not? > > Yes, go ahead. Too late, I #ifdeffed instead:-) >> (...) >> I do not understand the calls to ldap_pvt_thread_pool_context_reset() >> in slapd (init.c and bconfig.c). That frees the thread's sl_malloc >> memory with slap_sl_mem_destroy(), which seems rather hazardous until >> the thread is really, really done. > > Those calls are from the main thread, and only occur during startup. And in slap_destroy(). > The point is to free up that memory since the main thread will never > need it again. Ah. I guess I need to figure out just what is allowed to use slap_sl_malloc() and what isn't. >> For that matter, I guess that means context_reset() had better release >> keys in the reverse order of how they were set. That usually happened, >> but not always, and my clear_key_idx() made the "not always" more >> common. So to close the gap from a deleted key I'll make it move all >> later keys forward, instead of just moving the latest key to the gap. > > I don't think the order is really important... ?? Well, I was thinking if some key could manage to get in front of the sl_malloc key and then be deleted, and then some key which sl_malloced memory ended up before it. But as noted above I don't have a clue:-) Also see tpool.c 1.30.2.17: "ITS#4805 free thread keys in reverse order". However I don't see from the ITS notes how it is related. >> Bdb uses the database environment address as a key to pool_setkey(). >> So there can be at most ~30 BDB databases with an active key at the >> same time in the same thread. What does that mean - 30 overlays >> all using bdb? Access control groups spanning 30 databases? > > Seems so. We could raise this limit if it's a problem, but I don't see > why anyone would use 30 separate databases instead of just one. > Configuring the caches would be a real bear... Well, it's the most natural way to set up an LDAP hotel - 1 database per hosted organization, where each org can configure its own indexes etc. But cache config is definitely an argument against it. It's no less strange to have e.g. 100 databases than 30, so I'm not suggesting to raise the limit in OpenLDAP. Though I suppose we could make it a default, overridden by CPPFLAGS=-DLDAP_THREAD_MAXKEYS=<num>. >> Nitpick: Slapd uses both function pointers and data pointers as keys to >> pool_[sg]etkey(). That makes it possible for two "different" keys to >> compare equal, on a host where functions and data live in different >> segments that otherwise share the same address space. So I guess I >> should clean up and replace (void*)<function> keys with the address of >> static char <function>_key; > > Hosts such as ... ? Not even OS/390 is so strange. Don't know, but it wouldn't surprise me if SINTRAN on ND-500 worked that way. What I do remember is that a program or library consisted of 2-3 files: program segment, data segment and optionally link segment. But it's likely less uncommon for function pointers to be wider than data pointers, which OpenLDAP doesn't support anyway. > The use of function pointers was just a convenience, since the address > is guaranteed to be a unique value within the process and easily > recognizable in a debugger. We could easily use addresses of static > variables instead but it's silly to introduce new variables just for > this purpose. Someday I want to revisit this and use OS-supported thread-specific keys, then it'll change anyway. -- Regards, Hallvard

1 0

(ITS#4990) memory debugging issues
by h.b.furuseth＠usit.uio.no 31 May '07

31 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard CPPFLAGS=-DLDAP_MEMORY_DEBUG won't build: ber_int_meminuse is not defined. sl_malloc.c needs s/ber_malloc_x/ber_memalloc_x/ under SLAP_NO_SL_MALLOC. There are both #if and #ifdef LDAP_MEMORY_DEBUG statements, but value 0 breaks compilation. LDAP_MEMORY_DEBUG enables a number of assert()s that break OpenLDAP code, like ldap_control_free(NULL). Until they are cleaned up (if they are still considered errors) I'll disable them by default unless LDAP_MEMORY_DEBUG & 2. Could do the opposite if someone wants. I'll insert LDAP_MEMORY_DEBUG code in slap_sl_malloc() as well (insert memory signature before each returned chunk, check upon free/realloc).

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 31 May '07

31 May '07

h.b.furuseth(a)usit.uio.no wrote: > I wrote in the tpool.c 1.66 -> 1.67 patch: > >> API changes, need review - I'm not sure what's indented here: >> - setkey(data=NULL, kfree!=NULL) searched as if intended to reset >> the key, but updated by setting the key. Now always updates. > > Right. That matches the one place it can happen: In bdb_locker_id() > with setkey(,,data=(void *)(long)lockid,). I don't know if lockid > can be 0, but it doesn't need to for data to be NULL. lockid will never be zero. > But it would cleaner to ch_malloc an integer instead of the (void*) > cast. Then it won't depend on integer->pointer->integer conversions > preserving the value either. Ugh. That's just silly. We should just typedef a union that's big enough to hold a pointer or an integer... > BTW, is there a reason for the cast to long? lockid is u_int32_t, > and the getkey 'long' result is restored to a u_int32_t. I don't recall. > Howard Chu wrote: > >>> Also if ctx is invalid (another thread handled it) and a new >>> pending request has gotten the now-unused ctx, then the >>> 'if (pool->ltp_open_count == 0)' code will free that new >>> pending request instead of the old one. >> Most likely this is due to unlocking and relocking the mutex around >> the semaphore code. Axe that, remove the gratuitous unlock/relock, >> and then that problem goes away. > > Was that an instruction/permission to axe it or not? Yes, go ahead. > If not I'll just move the unlock/lock into the #ifdef for now. > >> Thus far we've only had to worry about a single pool. If anyone can >> come up with a reason to need multiple pools, I guess we need to >> hear it. > > I'll insert "static int initialized; assert(!initialized++);" > in pool_init() and see if anyone complains. Sounds fine. >>> - setkey does not free the old data with ltk_free. Possibly that's >>> intentional, but if so that requires weird code elsewhere. >> Yes, that's intentional. ltk_free is only intended for cleanup if a key >> is still set by the time a thread exits. All of the keys we set are live >> for the entire life of a thread, they don't get re-assigned. > > Even the (void*)slap_sasl_bind key? > lutil_passwd() looks like it can be recursive: Register a password > scheme which finds an entry in LDAP and authenticates via that > entry's userPassword - which again could call lutil_passwd(). > If that's legal, this code in be_isroot_pw()/slap_passwd_check() > can break: > pool_setkey(, slap_sasl_bind, <ctx>, <freefunc> ); > ... /* slap_passwd_check() does access_allowed() here */ > lutil_passwd(); > ... > pool_setkey(, slap_sasl_bind, NULL, NULL); > The final setkey would need to restore the old key. I guess so. > I'm not sure of contrib/slapd-modules/smbk5pwd/smbk5pwd.c + some > overlay either. rwm + back-relay which uses another smbk5pwd or > something. (And I have no idea of the BDB cache stuff, but since > you wrote it I assume you know:-) > > If it's a problem, we can replace code like that with > void *data = <ctx>; > ldap_pvt_thread_pool_keyfree_t *kfree = <freefunc>; > pool_swapkey(, slap_sasl_bind, &data, &kfree ); /* new function */ > lutil_passwd(); > pool_setkey(, slap_sasl_bind, data, kfree ); > or if setkey reverts to ignoring kfree when it checks whether we are > setting or deleting a key, the kfree function can be passed directly. > > > I wrote: > >> But this reminds me: How much should an ltk_free() function be allowed >> to do? >> - pool_context_reset() calls ltk_free(). Should pool_wrapper() go >> active (wait for !pause, increment ltp_active_count, unlock ltp_mutex) >> before calling pool_context_reset()? > > I think so. It makes slapi safer, and I don't see that it can hurt: > context_reset() can call connection_fake_destroy(), which via > slapi_int_free_object_extensions() calls slapi module destructors, > which can do who-knows-what. > > Another stray thought: It would similarly be safer for context_reset() > and purgekey() to delete the key before calling ltk_free, so that > function can't access the key's data after freeing it. OTOH that would > break any slapi module whose ltk_free calls a function which uses the > key before freeing it. I'll leave it alone unless someone says otherwise. > > > Other matters: > > pool->ltp_active_list is maintained but not used for anything. > Do I delete it? Or does tpool maintain the list to ease debugging? No idea. > Use of tpool: > > Another bug: > Slapd does not always check if pool_submit() and pool_setkey() succeed, > even though failure is not a bug. (They can run into some limits.) > > > I do not understand the calls to ldap_pvt_thread_pool_context_reset() > in slapd (init.c and bconfig.c). That frees the thread's sl_malloc > memory with slap_sl_mem_destroy(), which seems rather hazardous until > the thread is really, really done. Those calls are from the main thread, and only occur during startup. The point is to free up that memory since the main thread will never need it again. > For that matter, I guess that means context_reset() had better release > keys in the reverse order of how they were set. That usually happened, > but not always, and my clear_key_idx() made the "not always" more > common. So to close the gap from a deleted key I'll make it move all > later keys forward, instead of just moving the latest key to the gap. I don't think the order is really important... ?? > Bdb uses the database environment address as a key to pool_setkey(). > So there can be at most ~30 BDB databases with an active key at the > same time in the same thread. What does that mean - 30 overlays > all using bdb? Access control groups spanning 30 databases? Seems so. We could raise this limit if it's a problem, but I don't see why anyone would use 30 separate databases instead of just one. Configuring the caches would be a real bear... > Nitpick: Slapd uses both function pointers and data pointers as keys to > pool_[sg]etkey(). That makes it possible for two "different" keys to > compare equal, on a host where functions and data live in different > segments that otherwise share the same address space. So I guess I > should clean up and replace (void*)<function> keys with the address of > static char <function>_key; Hosts such as ... ? Not even OS/390 is so strange. The use of function pointers was just a convenience, since the address is guaranteed to be a unique value within the process and easily recognizable in a debugger. We could easily use addresses of static variables instead but it's silly to introduce new variables just for this purpose. -- -- 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#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de 31 May '07

31 May '07

Full_Name: Christian Marg Version: 2.3.34 OS: FreeBSD 6.2-RELEASE-p3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.3.23.106) I found a behaviour issue with the dynlist overlay configuration: I tried the following configuration: overlay dynlist dynlist-attrset posixGroup memberURL dynlist-attrset groupOfURLs memberURL owner but slaptest complains about it - and the slapd doesn't start with it: @(#) $OpenLDAP: slapd 2.3.34[...] /usr/local/etc/openldap/slapd.conf: line 91: "dynlist-attrset <oc> <URL-ad> [<member-ad>]": URL attributeDescription "memberURL" already mapped. slapd stopped. When I use multiple "overlay dynlist"-entries like: overlay dynlist dynlist-attrset posixGroup memberURL overlay dynlist dynlist-attrset groupOfURLs memberURL owner it works as expected, but there is a warning: overlay_config(): warning, overlay "dynlist" already in list PS: Although the new Version 2.3.35 isn't available via FreeBSD Ports yet, I don't think that it would change anything, because the source file of the dynlist-overlay doesn't seem to have changed in any part that matters to this issue.

1 0

Quirk in Dynlist overlay configuration
by Christian Marg 30 May '07

30 May '07

Hello, in the FAQ-o-Matic http://www.openldap.org/faq/index.cgi?file=1209 it says Unlike previous versions, you do not have to have multiple overlay dynlist entries in your configuration; multiple occurrences of the dynlist-attrpair/ dynlist-attrset statement must be used instead, with a caveat: only the first match on the dyn-oc is used. I tried this with the following configuration: overlay dynlist dynlist-attrset posixGroup memberURL dynlist-attrset groupOfURLs memberURL owner but slaptest complains about it - and the slapd doesn't start with it: @(#) $OpenLDAP: slapd 2.3.34[...] /usr/local/etc/openldap/slapd.conf: line 91: "dynlist-attrset <oc> <URL-ad> [<member-ad>]": URL attributeDescription "memberURL" already mapped. slapd stopped. When I use multiple "overlay dynlist"-entries like: overlay dynlist dynlist-attrset posixGroup memberURL overlay dynlist dynlist-attrset groupOfURLs memberURL owner it works as expected, even though there is a warning: overlay_config(): warning, overlay "dynlist" already in list BTW: Although the new Version 2.3.35 isn't available via FreeBSD Ports yet, I don't think that it would change anything, because the source file of the dynlist-overlay doesn't seem to have changed in any part that matters to this issue. bye Christian -- Christian Marg mail: mailto:marg@rz.tu-clausthal.de Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : <on request>

2 1

Re: (ITS#4980) misaligned memory access (openssl?)
by richton＠nbcs.rutgers.edu 30 May '07

30 May '07

I'm going to claim this as possible corruption because the RADIUS module was definitely overstepping bounds when this happened...feel free to close this out, I'll keep an eye out for recurrences. On Wed, 23 May 2007, Howard Chu wrote: > This stack trace is pretty exclusively OpenSSL and libc code. Unless there's > been a heap corruption somewhere, it appears to be an OpenSSL issue.

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 30 May '07

30 May '07

I think this does it; I'm now happy with RADIUS in production. --- ldap-src/contrib/slapd-modules/passwd/radius.c 2007-05-30 19:38:29.210866000 -0400 +++ radius.c 2007-05-29 11:02:09.728936000 -0400 @@ -17,6 +17,7 @@ #include <lber.h> #include <lber_pvt.h> /* BER_BVC definition */ #include "lutil.h" +#include <portable.h> #include <ldap_pvt_thread.h> #include <ac/string.h> #include <ac/unistd.h> On Tue, 29 May 2007, Aaron Richton wrote: > Boy, that was some real quality time with dbx...ugh. > > > I'm fairly confident that the issue is that portable.h isn't included and > should have been as part of my patch. This worked in a development > environment; I'll be putting it through some more tests and, most likely, in > production soon (the =NULL workaround is just a time bomb).

1 0

Re: (ITS#4972) thr_debug problems
by h.b.furuseth＠usit.uio.no 30 May '07

30 May '07

I wrote: > RE23/thr_debug.c has some other problems that are fixed in HEAD, but > take a bit more work to fix and test. I'll align it with HEAD if > anyone is interested. Apparenlty not. I'll import the fixes local to thr_debug.c to RE23, but not the ones that need changes in include/. -- Regards, Hallvard

1 0

(ITS#4988) --disable-overlays breaks overlays/Makefile
by h.b.furuseth＠usit.uio.no 29 May '07

29 May '07

Full_Name: Hallvard B Furuseth Version: RE23 OS: HPUX URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard 'make' on HP-UX does not like '\' - newline - blank line, produced by OBJS = overlays.o \ statover.o \ @SLAPD_STATIC_OVERLAYS@ in overlays/Makefile.in with --disable-overlays. Fixed in HEAD overlays/Makefile.in rev 1.46, importing to RE23 now.

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 29 May '07

29 May '07

Some more comments, review, planned changes, and questions. I guess I should summarize the bugs I've fixed in HEAD first, for completeness. (I was a bit too busy at the time.) Restating the CVS log comments, nothing new but maybe a bit clearer. Possibly some of the issues are tpool-only issues and can't happen the way slapd uses tpool. ---------------------------------------- rev 1.63: ldap_pvt_thread_pool_submit(), after failed thread creation: - ltp_pending_count++ should be --. - should signal if there are no more threads, in case pool_destroy() is waiting for that. (Not sure if that can happen.) ldap_int_thread_pool_wrapper(): - The 'if(ltp_state...)' was spurious: It would always be true, and if it were not we'd get an eternal loop. rev 1.64: pool_pause(): - would cancel states FINISHING and STOPPING, pool_resume() would set it back to RUNNING. - could hang when waiting for another pool_pause(), since it did not signal ltp_pcond if it decremented ltp_active_count to 1. pool_wrapper(): - could update thread_keys[] during a pause while initializing and possibly while finishing, - just after initializing, could handle a new ctx during a pause. pool_destroy(): - would go on with destruction if pool_resume() was called, since it used an if(){wait} instead of while() and they use the same cond. rev 1.65: - pool_context() read thread_keys[] without mutex protection. pool_purgekey() too, but it expected a pause to protect the keys. pool_wrapper() protected with ltp_mutex while writing, and did not quite ensure a pause. rev 1.66: - thread_keys[] is a (poor) open-addessed hash table, but it lacked a "deleted item" mark. So keys (contexts) could become hidden and re-emerge later if threads exited and then new ones were started. - TID_HASH() did hash calculation in signed arithmetic, thus depending on friendly integer overflow. rev 1.67: - setkey/getkey expected ldap_int_thread_userctx_t.ltu_key[] to be NULL-terminated when not full. purgekey() could set a NULL in the middle, hiding later keys until a new key overwrote the NULL. API changes: - setkey(data=NULL, kfree!=NULL) searched as if intended to reset the key, but updated by setting the key. Now always updates. - setkey(key=<not found>, data=NULL) could return either success or failure. Now succeeds iff (data == NULL && kfree == NULL). rev 1.68: - ltp_max_count <= 0 meant allow an unlimited number of threads, but thread #LDAP_MAXTHR+1 and later would loop forever looking for a free thread_keys[] slot. (Not fixed for multi-pool applications.) ---------------------------------------- I wrote in the tpool.c 1.66 -> 1.67 patch: > API changes, need review - I'm not sure what's indented here: > - setkey(data=NULL, kfree!=NULL) searched as if intended to reset > the key, but updated by setting the key. Now always updates. Right. That matches the one place it can happen: In bdb_locker_id() with setkey(,,data=(void *)(long)lockid,). I don't know if lockid can be 0, but it doesn't need to for data to be NULL. But it would cleaner to ch_malloc an integer instead of the (void*) cast. Then it won't depend on integer->pointer->integer conversions preserving the value either. BTW, is there a reason for the cast to long? lockid is u_int32_t, and the getkey 'long' result is restored to a u_int32_t. Howard Chu wrote: >> Also if ctx is invalid (another thread handled it) and a new >> pending request has gotten the now-unused ctx, then the >> 'if (pool->ltp_open_count == 0)' code will free that new >> pending request instead of the old one. > > Most likely this is due to unlocking and relocking the mutex around > the semaphore code. Axe that, remove the gratuitous unlock/relock, > and then that problem goes away. Was that an instruction/permission to axe it or not? If not I'll just move the unlock/lock into the #ifdef for now. > Thus far we've only had to worry about a single pool. If anyone can > come up with a reason to need multiple pools, I guess we need to > hear it. I'll insert "static int initialized; assert(!initialized++);" in pool_init() and see if anyone complains. >> - setkey does not free the old data with ltk_free. Possibly that's >> intentional, but if so that requires weird code elsewhere. > > Yes, that's intentional. ltk_free is only intended for cleanup if a key > is still set by the time a thread exits. All of the keys we set are live > for the entire life of a thread, they don't get re-assigned. Even the (void*)slap_sasl_bind key? lutil_passwd() looks like it can be recursive: Register a password scheme which finds an entry in LDAP and authenticates via that entry's userPassword - which again could call lutil_passwd(). If that's legal, this code in be_isroot_pw()/slap_passwd_check() can break: pool_setkey(, slap_sasl_bind, <ctx>, <freefunc> ); ... /* slap_passwd_check() does access_allowed() here */ lutil_passwd(); ... pool_setkey(, slap_sasl_bind, NULL, NULL); The final setkey would need to restore the old key. I'm not sure of contrib/slapd-modules/smbk5pwd/smbk5pwd.c + some overlay either. rwm + back-relay which uses another smbk5pwd or something. (And I have no idea of the BDB cache stuff, but since you wrote it I assume you know:-) If it's a problem, we can replace code like that with void *data = <ctx>; ldap_pvt_thread_pool_keyfree_t *kfree = <freefunc>; pool_swapkey(, slap_sasl_bind, &data, &kfree ); /* new function */ lutil_passwd(); pool_setkey(, slap_sasl_bind, data, kfree ); or if setkey reverts to ignoring kfree when it checks whether we are setting or deleting a key, the kfree function can be passed directly. I wrote: > But this reminds me: How much should an ltk_free() function be allowed > to do? > - pool_context_reset() calls ltk_free(). Should pool_wrapper() go > active (wait for !pause, increment ltp_active_count, unlock ltp_mutex) > before calling pool_context_reset()? I think so. It makes slapi safer, and I don't see that it can hurt: context_reset() can call connection_fake_destroy(), which via slapi_int_free_object_extensions() calls slapi module destructors, which can do who-knows-what. Another stray thought: It would similarly be safer for context_reset() and purgekey() to delete the key before calling ltk_free, so that function can't access the key's data after freeing it. OTOH that would break any slapi module whose ltk_free calls a function which uses the key before freeing it. I'll leave it alone unless someone says otherwise. Other matters: pool->ltp_active_list is maintained but not used for anything. Do I delete it? Or does tpool maintain the list to ease debugging? Use of tpool: Another bug: Slapd does not always check if pool_submit() and pool_setkey() succeed, even though failure is not a bug. (They can run into some limits.) I do not understand the calls to ldap_pvt_thread_pool_context_reset() in slapd (init.c and bconfig.c). That frees the thread's sl_malloc memory with slap_sl_mem_destroy(), which seems rather hazardous until the thread is really, really done. For that matter, I guess that means context_reset() had better release keys in the reverse order of how they were set. That usually happened, but not always, and my clear_key_idx() made the "not always" more common. So to close the gap from a deleted key I'll make it move all later keys forward, instead of just moving the latest key to the gap. Bdb uses the database environment address as a key to pool_setkey(). So there can be at most ~30 BDB databases with an active key at the same time in the same thread. What does that mean - 30 overlays all using bdb? Access control groups spanning 30 databases? Nitpick: Slapd uses both function pointers and data pointers as keys to pool_[sg]etkey(). That makes it possible for two "different" keys to compare equal, on a host where functions and data live in different segments that otherwise share the same address space. So I guess I should clean up and replace (void*)<function> keys with the address of static char <function>_key; -- Regards, Hallvard

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 29 May '07

29 May '07

Boy, that was some real quality time with dbx...ugh. I'm fairly confident that the issue is that portable.h isn't included and should have been as part of my patch. This worked in a development environment; I'll be putting it through some more tests and, most likely, in production soon (the =NULL workaround is just a time bomb). On Thu, 24 May 2007, Aaron Richton wrote: > On Tue, 22 May 2007, Pierangelo Masarati wrote: >> If that's an issue, I have no problem in explicitly setting that pointer >> to NULL. > > I got some more dbx time on this, and it looks like that's a workaround for > something that shouldn't be happening/needs to be fixed anyway. > config_filename is always NULL at dlopen() time, just as it should be. > > Calling lock(&libradius_mutex) apparently overwrites config_filename, and > explicitly initializing to NULL somehow stops this from happening. I can't > see anything wrong with radius.c (as in HEAD), though; if anybody can weigh > in on this, it'd be much appreciated. I suppose it could still be a compiler > or a libthread bug, but I'm still missing a smoking gun here. > >

1 0

Re: (ITS#4985) pthread.h: present but cannot be compiled
by maugustine＠phsyes.com 29 May '07

29 May '07

This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C7A1C1.FB9C6800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For those of you that may have this same issue, I discovered that the problem was with gcc version 4.0.0 that loads with AIX 5.3. After I upgraded to 4.1.1, this problem went away. ------=_NextPart_000_0004_01C7A1C1.FB9C6800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <style>  </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><font size=3D2 face=3DArial><span = style=3D'font-size:10.0pt; font-family:Arial'>For those of you that may have this same issue, I = discovered that the problem was with gcc version 4.0.0 that loads with AIX = 5.3.  After I upgraded to 4.1.1, this problem went away.<o:p></o:p></span></font></p> </div> </body> </html> ------=_NextPart_000_0004_01C7A1C1.FB9C6800--

1 0

(ITS#4987) imporvement to slapo-constraint
by manu＠netbsd.org 28 May '07

28 May '07

Full_Name: Emmanuel Dreyfus Version: 4.4.4 OS: NetBSD URL: ftp://ftp.openldap.org/incoming/manu-070529.ext Submission from: (NULL) (213.41.141.172) I modified slapo-constraint so that it can verify that an attribute value is bound to the existing values of another attribute. The purpose is to make referential integrity easier to obtain. Attached is a draft patch for review. Then there is the UI question. For now it's configured in slapd.conf like this: database bdb suffix "dc=example,dc=net" overlay constraint constraint_attribute title key netExampleTitle Which means that add and modify on title will fail if the new value is not an existing netExampleTitle value. I used the keyword "key" with RDBMS referential integrity in mind, but I'm not sure it's that clear in this context. Suggestions are welcome. The update to man page is missing yet. I know. Also, I had trouble understanding the style used in these sources. Is there an official style guide for OpenLDAP?

1 0

(ITS#4986) manageDSAit might control cause problems in database selection
by nvoutsin＠noc.uoa.gr 28 May '07

28 May '07

Full_Name: Nikos Voutsinas Version: 2.3.35 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.134.100.207) With the following configuration, search operations in the local database ("dc=foo,dc=bar") will fail when manageDSAit control is set. .... .... backend bdb database bdb suffix "dc=foo,dc=bar" rootdn "uid=manager,dc=foo,dc=bar" rootpw "secret" directory /var/openldap/bdb access to * by * read database relay suffix "" relay "dc=foo,dc=bar" massage access to * by * read .... .... The problem has been tracked down in select_backend().

1 0

(ITS#4985) pthread.h: present but cannot be compiled
by maugustine＠phsyes.com 25 May '07

25 May '07

Full_Name: Matt Augustine Version: 2.3.32 OS: AIX 5.3 URL: Submission from: (NULL) (208.8.86.2) Dear help, I have currently installed openssl-0.9.8e and am looking to install openldap-2.3.32 on AIX 5.3. However, when I go to run the configure script it ends with the following warning: pthread.h: present but cannot be compiled / check for missing prerequisite headers? / see the Autoconf documentation secion "Present But cannot Be Compiled" proceeing with the preprocessor's result / in the future, the compiler will take precedence / Report this to <http://www.openldap.org/its/> I then went to check the config.log and tied it to the following errors: /usr/include/pthread.h:666: error: parse error before '*' token /usr/include/pthread.h:669: error: parse error before '*' token /usr/include/pthread.h:672: error: parse error before '*' token /usr/include/pthread.h:675: error: parse error before '*' token /usr/include/pthread.h:678: error: parse error before '*' token /usr/include/pthread.h:686: error: parse error before '*' token /usr/include/pthread.h:689: error: parse error before '*' token /usr/include/pthread.h:692: error: parse error before '*' token /usr/include/pthread.h:695: error: parse error before '*' token /usr/include/pthread.h:703: error: parse error before '*' token /usr/include/pthread.h:707: error: parse error before '*' token /usr/include/pthread.h:710: error: parse error before '*' token Those lines in pthread.h correspond to the following: 666: pthread_spin_init __((pthread_spinlock_t *, int)); 669: pthread_spin_destroy __((pthread_spinlock_t *)); 672: pthread_spin_lock __((pthread_spinlock_t *)); 675: pthread_spin_unlock __((pthread_spinlock_t *)); 678: pthread_spin_trylock __((pthread_spinlock_t *)); 686: pthread_barrierattr_init __((pthread_barrierattr_t *)); 689: pthread_barrierattr_destroy __((pthread_barrierattr_t *)); 692: pthread_barrierattr_getpshared __((const pthread_barrierattr_t *__restrict__, int *__restrict__)); 695: pthread_barrierattr_setpshared __((pthread_barrierattr_t *, int)); 703: pthread_barrier_init __((pthread_barrier_t *__restrict__, const pthread_barrierattr_t *__restrict__, unsigned)); 707: pthread_barrier_destroy __((pthread_barrier_t *)); 710: pthread_barrier_wait __((pthread_barrier_t *)); Unfortunately, I'm fairly new to AIX, and building things from source, so these lines really don't mean much to me. Any help that you can provide would be greatly appreciated. Thanks!

1 0

Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by hyc＠symas.com 24 May '07

24 May '07

eagle(a)windlord.stanford.edu wrote: > We've reproduced the crash and I have it in a crashed state in gdb right > now. Should be fixed now in valsort.c in HEAD. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1107294576 (LWP 32735)] > valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455 > 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) { > (gdb) bt > #0 valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455 > #1 0x0000000000478a2a in overlay_op_walk (op=0x2aabaeae0058, rs=0x41ffef10, > which=op_modify, oi=0x2b240a786518, on=0x2b240a786cd8) at backover.c:498 > #2 0x0000000000478e65 in over_op_func (op=0x2aabaeae0058, rs=0x41ffef10, > which=op_modify) at backover.c:560 > #3 0x000000000043c962 in fe_op_modify (op=0x2aabaeae0058, rs=0x41ffef10) > at modify.c:395 > #4 0x000000000043d45a in do_modify (op=0x2aabaeae0058, rs=0x41ffef10) > at modify.c:200 > #5 0x0000000000427af9 in connection_operation (ctx=Variable "ctx" is not available. > ) at connection.c:1133 > #6 0x0000000000427fa4 in connection_read_thread (ctx=0x41fff060, argv=Variable "argv" is not available. > ) > at connection.c:1261 > #7 0x00002b2408673894 in ldap_int_thread_pool_wrapper (xpool=0x2b2409d10058) > at tpool.c:478 > #8 0x00002b24083ad9af in startMeUp () from /usr/local/lib/libhoard.so > #9 0x00002b24090bfb55 in start_thread () from /lib/libpthread.so.0 > #10 0x00002b24092a07f0 in clone () from /lib/libc.so.6 > [...] > (gdb) frame 0 > #0 valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455 > 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) { > (gdb) list > 450 if ( ml->sml_desc == vi->vi_ad ) > 451 break; > 452 } > 453 if ( !ml ) > 454 continue; > 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) { > 456 ptr = ber_bvchr(&ml->sml_values[i], '{' ); > 457 if ( !ptr ) { > 458 Debug(LDAP_DEBUG_TRACE, "weight missing from attribute %s\n", > 459 vi->vi_ad->ad_cname.bv_val, 0, 0); > (gdb) print *ml > $2 = {sml_mod = {sm_op = 1, sm_flags = 0, sm_desc = 0x2b2409a344d0, sm_type = { > bv_len = 20, bv_val = 0x2aabaea1f8e9 "suorgcontactstanford"}, > sm_values = 0x0, sm_nvalues = 0x0}, sml_next = 0x2aabaeaf4770} > (gdb) print i > No symbol "i" in current context. > (gdb) print ml->sml_mod.sm_values > $3 = 0x0 > > I'll leave it running in gdb so that I can find additional information for > you as needed. > > > -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support

1 0

Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by eagle＠windlord.stanford.edu 24 May '07

24 May '07

Here are the logs of the connection that led to the crash. We think that it may be attempting a delete after the last logged MOD, but so far we haven't been able to get any more detailed information from the authors of the application making the change. May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=0 BIND dn="" method=163 May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=0 RESULT tag=97 err=14 text= May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=1 BIND dn="" method=163 May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=1 RESULT tag=97 err=14 text= May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=2 BIND dn="" method=163 May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=2 BIND authcid="service/slog-org(a)stanford.edu" authzid="service/slog-org(a)stanford.edu" May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=2 BIND dn="cn=slog-org,cn=service,cn=applications,dc=stanford,dc=edu" mech=GSSAPI ssf=56 May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=2 RESULT tag=97 err=0 text= May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=3 SRCH base="" scope=0 deref=3 filter="(objectClass=*)" May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=3 SRCH attr=subschemasubentry May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=4 SRCH base="cn=Subschema" scope=0 deref=3 filter="(objectClass=subschema)" May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=4 SRCH attr=objectClasses attributeTypes matchingRules ldapSyntaxes objectClass javaSerializedData javaClassName javaFactory javaCodeBase javaReferenceAddress javaClassNames javaRemoteLocation May 24 14:34:01 ldap-test0 slapd[32729]: conn=13 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= May 24 14:34:02 ldap-test0 slapd[32729]: conn=12 op=5 ABANDON msg=5 May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=5 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=0 deref=3 filter="(objectClass=*)" May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=5 SEARCH RESULT tag=101 err=0 nentries=1 text= May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=6 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=1 deref=3 filter="(suRegID=dab33c07fe4f5bee9901a10446424016)" May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=6 SEARCH RESULT tag=101 err=0 nentries=1 text= May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=7 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=0 deref=3 filter="(objectClass=*)" May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=7 SEARCH RESULT tag=101 err=0 nentries=1 text= May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=8 MOD dn="suRegID=dab33c07fe4f5bee9901a10446424016,cn=organizations,dc=stanford,dc=edu" May 24 14:34:08 ldap-test0 slapd[32729]: conn=13 op=8 MOD attr=sugeneralid suseealsoorgregid suorgcontactstanford May 24 14:34:09 ldap-test0 slapd[32729]: conn=13 op=8 RESULT tag=103 err=0 text= May 24 14:34:11 ldap-test0 slapd[32729]: conn=13 op=9 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=0 deref=3 filter="(objectClass=*)" May 24 14:34:11 ldap-test0 slapd[32729]: conn=13 op=9 SEARCH RESULT tag=101 err=0 nentries=1 text= May 24 14:34:11 ldap-test0 slapd[32729]: conn=13 op=10 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=1 deref=3 filter="(suRegID=dab33c07fe4f5bee9901a10446424016)" May 24 14:34:11 ldap-test0 slapd[32729]: conn=13 op=10 SEARCH RESULT tag=101 err=0 nentries=1 text= May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=11 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=0 deref=3 filter="(objectClass=*)" May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=11 SEARCH RESULT tag=101 err=0 nentries=1 text= May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=12 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=1 deref=3 filter="(suRegID=41559190986611d3acf6ab400b0baa77)" May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=12 SEARCH RESULT tag=101 err=0 nentries=1 text= May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=13 SRCH base="cn=organizations,dc=stanford,dc=edu" scope=0 deref=3 filter="(objectClass=*)" May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=13 SEARCH RESULT tag=101 err=0 nentries=1 text= May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=14 MOD dn="suRegID=41559190986611d3acf6ab400b0baa77,cn=organizations,dc=stanford,dc=edu" May 24 14:34:12 ldap-test0 slapd[32729]: conn=13 op=14 MOD attr=suorgcontactlabelstanford eduorghomepageuri telephonenumber sugworgaddress facsimiletelephonenumber street postaladdress suorgcontactstanford suprintsection labeleduri sugeneralid and then crash.

1 0

Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by eagle＠windlord.stanford.edu 24 May '07

24 May '07

We've reproduced the crash and I have it in a crashed state in gdb right now. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1107294576 (LWP 32735)] valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) { (gdb) bt #0 valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455 #1 0x0000000000478a2a in overlay_op_walk (op=0x2aabaeae0058, rs=0x41ffef10, which=op_modify, oi=0x2b240a786518, on=0x2b240a786cd8) at backover.c:498 #2 0x0000000000478e65 in over_op_func (op=0x2aabaeae0058, rs=0x41ffef10, which=op_modify) at backover.c:560 #3 0x000000000043c962 in fe_op_modify (op=0x2aabaeae0058, rs=0x41ffef10) at modify.c:395 #4 0x000000000043d45a in do_modify (op=0x2aabaeae0058, rs=0x41ffef10) at modify.c:200 #5 0x0000000000427af9 in connection_operation (ctx=Variable "ctx" is not available. ) at connection.c:1133 #6 0x0000000000427fa4 in connection_read_thread (ctx=0x41fff060, argv=Variable "argv" is not available. ) at connection.c:1261 #7 0x00002b2408673894 in ldap_int_thread_pool_wrapper (xpool=0x2b2409d10058) at tpool.c:478 #8 0x00002b24083ad9af in startMeUp () from /usr/local/lib/libhoard.so #9 0x00002b24090bfb55 in start_thread () from /lib/libpthread.so.0 #10 0x00002b24092a07f0 in clone () from /lib/libc.so.6 [...] (gdb) frame 0 #0 valsort_modify (op=0x2aabaeae0058, rs=0x41ffef10) at valsort.c:455 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) { (gdb) list 450 if ( ml->sml_desc == vi->vi_ad ) 451 break; 452 } 453 if ( !ml ) 454 continue; 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) { 456 ptr = ber_bvchr(&ml->sml_values[i], '{' ); 457 if ( !ptr ) { 458 Debug(LDAP_DEBUG_TRACE, "weight missing from attribute %s\n", 459 vi->vi_ad->ad_cname.bv_val, 0, 0); (gdb) print *ml $2 = {sml_mod = {sm_op = 1, sm_flags = 0, sm_desc = 0x2b2409a344d0, sm_type = { bv_len = 20, bv_val = 0x2aabaea1f8e9 "suorgcontactstanford"}, sm_values = 0x0, sm_nvalues = 0x0}, sml_next = 0x2aabaeaf4770} (gdb) print i No symbol "i" in current context. (gdb) print ml->sml_mod.sm_values $3 = 0x0 I'll leave it running in gdb so that I can find additional information for you as needed.

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by h.b.furuseth＠usit.uio.no 24 May '07

24 May '07

ali.pouya(a)free.fr writes: > tls.c:2908: error: syntax error before '*' token > tls.c: In function `find_oid': > (...) That's from ITS#4975: The code was broken for builds without TLS. It's been fixed in HEAD. Does it work now? -- Regards, Hallvard

1 0

Re: AW: Documentation error in "ppolicy.schema" (ITS#4984)
by hyc＠symas.com 24 May '07

24 May '07

The text in this schema file comes directly from the IETF draft. It should not be changed unless the draft itself has changed. This ITS should be closed. arnim.rupp(a)lhsystems.com wrote: > hi Gavin, > > i think the sentence is ok, just in the wrong place. just move this sentence: > > # This attribute is not set > # due to any actions specified by this document, it is typically set by > # a password administrator after resetting a user's password. > > from "5.2.13 pwdMustChange" to "5.3.7 pwdReset". > > regards > arnim rupp > > --- > Arnim Rupp > > Lufthansa Systems Infratec GmbH > Middleware Competence Center > FRA AI/A-AM > > Am Weiher 24 > 65451 Kelsterbach > Germany > > Raum/Room: 4.U1.07 LIC A > > Tel: +49-69-696-94944 > Fax: +49-69-696-93932 > > Email: arnim.rupp(a)lhsystems.com > Internet: www.lhsystems.com > > Sitz der Gesellschaft/Corporate Headquarters: > Lufthansa Systems Infratec GmbH, Kelsterbach > > Registereintragung/Registration: > Amtsgericht Darmstadt HRB 83851 > > Vorsitzender des Aufsichtsrates/ > Chairman of the Supervisory Board: > Dr. Gunter Küchler > > Geschäftsführung/Management: > Dr. Hannes Pfister > > > > >> -----Ursprüngliche Nachricht----- >> Von: Gavin Henry [mailto:openldap-its@OpenLDAP.org] >> Gesendet: Donnerstag, 24. Mai 2007 16:01 >> An: RUPP, ARNIM >> Cc: openldap-its(a)OpenLDAP.org >> Betreff: Re: Documentation error in "ppolicy.schema" (ITS#4984) >> >> Hi, >> >> Thank for your documentation report. >> >> How would you like it to be worded? >> >> Can you provide an example sentance? >> >> Thanks, >> >> Gavin. >> > > > -- -- 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

AW: Documentation error in "ppolicy.schema" (ITS#4984)
by arnim.rupp＠lhsystems.com 24 May '07

24 May '07

hi Gavin, i think the sentence is ok, just in the wrong place. just move this sentence: # This attribute is not set # due to any actions specified by this document, it is typically set by # a password administrator after resetting a user's password. from "5.2.13 pwdMustChange" to "5.3.7 pwdReset". regards arnim rupp --- Arnim Rupp Lufthansa Systems Infratec GmbH Middleware Competence Center FRA AI/A-AM Am Weiher 24 65451 Kelsterbach Germany Raum/Room: 4.U1.07 LIC A Tel: +49-69-696-94944 Fax: +49-69-696-93932 Email: arnim.rupp(a)lhsystems.com Internet: www.lhsystems.com Sitz der Gesellschaft/Corporate Headquarters: Lufthansa Systems Infratec GmbH, Kelsterbach Registereintragung/Registration: Amtsgericht Darmstadt HRB 83851 Vorsitzender des Aufsichtsrates/ Chairman of the Supervisory Board: Dr. Gunter Küchler Geschäftsführung/Management: Dr. Hannes Pfister > -----Ursprüngliche Nachricht----- > Von: Gavin Henry [mailto:openldap-its@OpenLDAP.org] > Gesendet: Donnerstag, 24. Mai 2007 16:01 > An: RUPP, ARNIM > Cc: openldap-its(a)OpenLDAP.org > Betreff: Re: Documentation error in "ppolicy.schema" (ITS#4984) > > Hi, > > Thank for your documentation report. > > How would you like it to be worded? > > Can you provide an example sentance? > > Thanks, > > Gavin. >

1 0

(ITS#4984) Documentation error in "ppolicy.schema"
by arnim.rupp＠lhsystems.com 24 May '07

24 May '07

Full_Name: arnim rupp Version: 2.3.35 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.106.39.109) hello, there's some wrong documentation in ./servers/slapd/schema/ppolicy.schema in the "chapter" #5.2.13 pwdMustChange is the sentence: # This attribute is not set # due to any actions specified by this document, it is typically set by # a password administrator after resetting a user's password. this doesn't make any sense there since no admin would change a server-wide setting after reseting a users password. instead it is missing in the chapter "#5.3.7 pwdReset". without this sentence it sounds like openldap automatically sets pwdReset (like good old netscape LDAP does). regards arnim

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 24 May '07

24 May '07

On Tue, 22 May 2007, Pierangelo Masarati wrote: > If that's an issue, I have no problem in explicitly setting that pointer > to NULL. I got some more dbx time on this, and it looks like that's a workaround for something that shouldn't be happening/needs to be fixed anyway. config_filename is always NULL at dlopen() time, just as it should be. Calling lock(&libradius_mutex) apparently overwrites config_filename, and explicitly initializing to NULL somehow stops this from happening. I can't see anything wrong with radius.c (as in HEAD), though; if anybody can weigh in on this, it'd be much appreciated. I suppose it could still be a compiler or a libthread bug, but I'm still missing a smoking gun here.

1 0

Re: (ITS#4981) Try -lpthread before -pthread
by kurt＠OpenLDAP.org 23 May '07

23 May '07

On May 23, 2007, at 10:16 PM, rra(a)stanford.edu wrote: > libtool does not pass -pthread through Our libtool does. But gcc might not do the right thing with it. In that case, it's a gcc bug which should be reported to the gcc folks. I believe using -lpthread over -pthread will cause more problems than its worth. That is, the problems caused by the missing link on some platforms is not nearly as bad as the caused by using -lc instead of -lc_r on other platforms. -- Kurt

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 23 May '07

23 May '07

rra(a)stanford.edu writes: > This issue, ITS#4982, is that no threading flags (not -pthread, not > -lpthread, not anything) are passed into the final link line of libldap_r, > as near as I can tell. Right. grepping make >& make.out shows no thread switch in the command line which builds libldap_r.so. Adding the ITS#4982 patch (and not ITS#4981), I got 4 '-pthread's in a row, which should be enough:-) -- Regards, Hallvard

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu 23 May '07

23 May '07

Kurt Zeilenga <kurt(a)OpenLDAP.org> writes: > libtool should properly handle -pthread. If it doesn't, that should be > fixed instead of kludging things up with -lpthread. -pthread tells gcc > to do the right thing. The right thing might not be to link in > -lpthread. (On some versions of FreeBSD, the right think is -lc_r.) > -pthread also might do more than link in a library. > As OpenLDAP includes its own copy of libtool, a local fix can be > provided until the upstream fixes it right. I think the above was meant for ITS #4981? This issue, ITS#4982, is that no threading flags (not -pthread, not -lpthread, not anything) are passed into the final link line of libldap_r, as near as I can tell. It's possible that I'm reading the makefile wrong and this has been fixed in some other way since the Debian patch had been applied, but libraries/libldap_r/Makefile.in contains: UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) and build/lib-shared.mk has: $(LIBRARY): version.lo $(LTLINK_LIB) -o $@ $(OBJS) version.lo $(LINK_LIBS) including only LINK_LIBS, and not the regular LIBS variable (which is what includes LTHREAD_LIBS via XXXLIBS). It could be that I'm missing some contribution to LTLINK_LIB handled by the threading macros, though. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by kurt＠OpenLDAP.org 23 May '07

23 May '07

libtool should properly handle -pthread. If it doesn't, that should be fixed instead of kludging things up with -lpthread. -pthread tells gcc to do the right thing. The right thing might not be to link in - lpthread. (On some versions of FreeBSD, the right think is -lc_r.) -pthread also might do more than link in a library. As OpenLDAP includes its own copy of libtool, a local fix can be provided until the upstream fixes it right. -- Kurt On May 24, 2007, at 1:25 AM, rra(a)stanford.edu wrote: > Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> writes: >> Hallvard B Furuseth writes: > >>> Is this the second half of the Debian patch you posted in >>> ITS#4981 - so >>> it'd be wrong to apply one one of these patches? > >> Sorry, "wrong to apply _only_ one of". > >> (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe >> everything worked well before we switched to libtool... > > No, they should be independent, I think. I believe that the > rationale for > 4982 is still correct; if you use pthread functions, you need to > explicitly link against the library to avoid getting unversioned > references. Unversioned references will *normally* not cause a > problem, > so they're a bit of a time bomb. They keep working fine right up > until > the library makes an incompatible change in the data structures, > and then > they break. > > -- > Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/ > ~eagle/> > >

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu 23 May '07

23 May '07

Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> writes: > Hallvard B Furuseth writes: >> Is this the second half of the Debian patch you posted in ITS#4981 - so >> it'd be wrong to apply one one of these patches? > Sorry, "wrong to apply _only_ one of". > (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe > everything worked well before we switched to libtool... No, they should be independent, I think. I believe that the rationale for 4982 is still correct; if you use pthread functions, you need to explicitly link against the library to avoid getting unversioned references. Unversioned references will *normally* not cause a problem, so they're a bit of a time bomb. They keep working fine right up until the library makes an incompatible change in the data structures, and then they break. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 23 May '07

23 May '07

Hallvard B Furuseth writes: > Is this the second half of the Debian patch you posted in ITS#4981 - so > it'd be wrong to apply one one of these patches? Sorry, "wrong to apply _only_ one of". (I.e. does ITS#4981 introduce breakage which ITS#4982 fixes?) Maybe everything worked well before we switched to libtool... -- Regards, Hallvard

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by h.b.furuseth＠usit.uio.no 23 May '07

23 May '07

rra(a)stanford.edu writes: > Since 2.2.23, Debian has been carrying the following patch to the libldap_r > build process to explicitly link the library against the thread libraries. > (...) Is this the second half of the Debian patch you posted in ITS#4981 - so it'd be wrong to apply one one of these patches? -- Regards, Hallvard

1 0

Re: (ITS#4981) Try -lpthread before -pthread
by h.b.furuseth＠usit.uio.no 23 May '07

23 May '07

rra(a)stanford.edu writes: > (...) libtool does not pass -pthread through, -lpthread seems > to work though. > (...) > + OL_PTHREAD_TRY([-lpthread], [ol_cv_pthread_lpthread]) > OL_PTHREAD_TRY([-pthread], [ol_cv_pthread_pthread]) > (...) This may be correct for Debian, but looks dubious as a general patch. On other systems that have a thread compiler switch it may be wrong to link the thread library "by hand" and omit the compiler switch, otherwise what's the compiler switch for? Their comments seem to indicate libtool is a better place to fix it. An OpenLDAP patch would likely need some 'if <debian>' code. (Note, I do not know Debian, nor specifics about differing Linux variants.) -- Regards, Hallvard

1 0

Re: (ITS#4983) libldap_r/tls.c compile failure
by h.b.furuseth＠usit.uio.no 23 May '07

23 May '07

kurt(a)OpenLDAP.org writes: > tls.c: In function `tls_thread_self': > tls.c:412: error: invalid operands to binary / > tls.c:415: warning: comparison between pointer and integer Well, that was quick... my tls.c rev 1.154 patch, tls_thread_self(), deliberately causes that for non-integer thread types. I wanted feedback from systems where that happens, since the OpenSSL doc says such systems are rare and this code can break there. The CRYPTO_set_id_callback manpage (from openssl/doc/crypto/threads.pod) says the function expects an integer thread ID, but that the function is not needed if getpid() returns different answers for different threads. And that this may be dangerous to relay on because one might compile a program on a machine where this is true and then run it on a machine where it is false. Anyway, possibly the correct fix is to not call this function on FreeBSD, it depends on getpid(). I have no idea. But since it presumably worked before: The simplest fix is to just remove the 'ok' and 'Check' code. But then we can again silently compile to bad code when the thread type is not an integer. Next simplest: simplify the 'ok' check to: enum { ok = sizeof(ldap_pvt_thread_t) <= sizeof(long) }; which will still let us know of systems where the conversion to ulong clearly loses data. Not quite a safe, since pointer<->integer conversions can do who-knows-what. But I guess OpenLDAP depends on those elsewhere. (Can sizeof(long) be < sizeof(pointer) on FreeBSD?) Also in any case cast tls_thread_self()'s return value to u.long. -- Regards, Hallvard

1 0

(ITS#4983) libldap_r/tls.c compile failure
by kurt＠OpenLDAP.org 23 May '07

23 May '07

Full_Name: Kurt Zeilenga Version: HEAD OS: FreeBSD RELENG_6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.182.55.218) Submitted by: kurt /bin/sh ../..//libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap -I/usr/local/include -I/usr/pkg/include/db44 -I/usr/pkg/include -DLDAP_LIBRARY -c tls.c cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap -I/usr/local/include -I/usr/pkg/include/db44 -I/usr/pkg/include -DLDAP_LIBRARY -c tls.c -fPIC -DPIC -o .libs/tls.o tls.c: In function `tls_thread_self': tls.c:412: error: invalid operands to binary / tls.c:415: warning: comparison between pointer and integer tls.c:415: error: enumerator value for `ok' not integer constant tls.c:416: error: negative width in bit-field `dummy' tls.c:416: error: size of array `Check' is negative tls.c:418: warning: return makes integer from pointer without a cast

1 0

(ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu 23 May '07

23 May '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.64.19.147) Since 2.2.23, Debian has been carrying the following patch to the libldap_r build process to explicitly link the library against the thread libraries. The comment at the time is: * libraries/libldap_r/Makefile.in: Code that uses pthreads *must* be linked with -pthread, even if it's a library; without this, the libldap_r library ends up with dangling unversioned reference to pthread_create() which gets resolved to a wrong version that causes segfaults on 64-bit platforms. Closes: #304549. See http://bugs.debian.org/304549 for the specific problems that this caused. --- openldap2.3-2.3.11~/libraries/libldap_r/Makefile.in 2005-12-01 13:48:50.000000000 +0100 +++ openldap2.3-2.3.11/libraries/libldap_r/Makefile.in 2005-12-02 10:05:17.637342000 +0100 @@ -56,7 +56,7 @@ XXLIBS = $(SECURITY_LIBS) $(LUTIL_LIBS) XXXLIBS = $(LTHREAD_LIBS) NT_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) -UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) +UNIX_LINK_LIBS = $(LDAP_LIBLBER_LA) $(AC_LIBS) $(SECURITY_LIBS) $(LTHREAD_LIBS) .links : Makefile @for i in $(XXSRCS); do \

1 0

(ITS#4981) Try -lpthread before -pthread
by rra＠stanford.edu 23 May '07

23 May '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.64.19.147) Debian has been carrying the included patch for a while, originally added against 2.1.22 with: + Fixed the undefined symbols in libldap_r.so.2 (closes: #195990). | configure.in: Try -lpthread before -pthread to link the thread library. libtool does not pass -pthread through, -lpthread seems to work though. and then refreshed some time later against 2.2.23 with: * configure.in: reinstate the remainder of the fix for 195990 from 2.1.22-2: give preference to -lpthread over -pthread in configure.in, because some archs (mipsel, at least) don't like -pthread. A quick search of other ITSes didn't reveal this particular report, but it did look like people building on AIX were manually setting library flags that may produce the same result. I'm sure that none of Debian's platforms will break with -lpthread instead of -pthread since we've been using this for a while, although I'm not sure if that's sufficient. I'd ideally like to see Debian stop carrying this patch around as a divergence, particularly since it means that the package has to re-run Autoconf during the build. Index: openldap2.3/configure.in =================================================================== --- openldap2.3.orig/configure.in 2007-05-23 15:05:12.000000000 -0700 +++ openldap2.3/configure.in 2007-05-23 15:09:38.000000000 -0700 @@ -1489,6 +1489,7 @@ case $ol_with_threads in auto | yes | po dnl OL_PTHREAD_TRY([-mt], [ol_cv_pthread_mt]) OL_PTHREAD_TRY([-kthread], [ol_cv_pthread_kthread]) + OL_PTHREAD_TRY([-lpthread], [ol_cv_pthread_lpthread]) OL_PTHREAD_TRY([-pthread], [ol_cv_pthread_pthread]) OL_PTHREAD_TRY([-pthreads], [ol_cv_pthread_pthreads]) OL_PTHREAD_TRY([-mthreads], [ol_cv_pthread_mthreads])

1 0

Re: (ITS#4980) misaligned memory access (openssl?)
by hyc＠symas.com 23 May '07

23 May '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.35 > OS: Solaris 9 > URL: > Submission from: (NULL) (128.6.31.135) > > > OpenSSL 0.9.8e. slapd crashed with SIGBUS on Solaris/sparcv9, which almost > always means a misaligned memory access. Not sure if this is OpenLDAP's problem > or OpenSSL, but figured I'd at least track here (can always go bug the OpenSSL > guys if necessary)... This stack trace is pretty exclusively OpenSSL and libc code. Unless there's been a heap corruption somewhere, it appears to be an OpenSSL issue. -- -- 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#4980) misaligned memory access (openssl?)
by richton＠nbcs.rutgers.edu 23 May '07

23 May '07

Full_Name: Aaron Richton Version: 2.3.35 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) OpenSSL 0.9.8e. slapd crashed with SIGBUS on Solaris/sparcv9, which almost always means a misaligned memory access. Not sure if this is OpenLDAP's problem or OpenSSL, but figured I'd at least track here (can always go bug the OpenSSL guys if necessary)... current thread: t@11 [1] t_delete(0x11c303480, 0x0, 0xffffffff7f268340, 0x2000, 0x2190, 0x1004e4290), at 0xffffffff7d24fab8 [2] _malloc_unlocked(0x80, 0x0, 0x0, 0x11ad552e0, 0x11ad552e0, 0x0), at 0xffffffff7d24f068 [3] malloc(0x80, 0xffffffff7e502458, 0xffffffff7e5014f0, 0xf68, 0x24fd00, 0xc00), at 0xffffffff7d24ee94 =>[4] CRYPTO_malloc(num = ???, file = ???, line = ???) (optimized), at 0xffffffff7e2b2274 (line ~304) in "mem.c" [5] bn_expand_internal(b = ???, words = ???) (optimized), at 0xffffffff7e308140 (line ~336) in "bn_lib.c" [6] BN_bin2bn(s = ???, len = ???, ret = ???) (optimized), at 0xffffffff7e308940 (line ~451) in "bn_lib.c" [7] RSA_eay_private_decrypt(flen = ???, from = ???, to = ???, rsa = ???, padding = ???) (optimized), at 0xffffffff7e32f160 (line ~517) in "rsa_eay.c" [8] ssl3_get_client_key_exchange(s = ???) (optimized), at 0xffffffff7e625150 (line ~1732) in "s3_srvr.c" [9] ssl3_accept(s = ???) (optimized), at 0xffffffff7e6227d0 (line ~449) in "s3_srvr.c" [10] ldap_pvt_tls_accept(sb = 0x11be3ac90, ctx_arg = 0x1004e4290), line 866 in "tls.c" [11] connection_read(s = 189), line 1348 in "connection.c" [12] slapd_daemon_task(ptr = (nil)), line 2359 in "daemon.c"

1 0

Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by nvoutsin＠noc.uoa.gr 23 May '07

23 May '07

Here is a simplified configuration that can be used to replicate the problem. I understand that such an error can not be easily triggered and in that sense might be considered as a low priority issue, but then again I believe it is worth mentioning. (I hope, I am not missing anything here...) # #include schemas here # access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by * none argsfile /var/openldap/run/slapd.args pidfile /var/openldap/run/slapd.pid loglevel any modulepath /opt/OpenLdap/sbin moduleload back_bdb.la moduleload back_relay.la moduleload rwm.la backend bdb database bdb suffix "dc=foo,dc=bar" rootdn "uid=manager,dc=foo,dc=bar" rootpw "secret" directory /var/openldap/bdb access to * by * read database relay suffix "" relay "dc=foo,dc=bar" massage access to * by * read As you can see from the logs below, ops like this one: SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)" SRCH attr=hasSubordinates objectClass fail, because slapd looks for an non-existent entry such as bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar"). The logs: ========= daemon: read activity on 11 connection_get(11) connection_get(11): got connid=0 connection_read(11): checking for input on id=0 daemon: select: listen=7 active_threads=0 tvp=NULL do_search >>> dnPrettyNormal: <dc=foo,dc=bar> <<< dnPrettyNormal: <dc=foo,dc=bar>, <dc=foo,dc=bar> SRCH "dc=foo,dc=bar" 1 0 0 0 0 begin get_filter PRESENT end get_filter 0 filter: (objectClass=*) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: hasSubordinates objectClass conn=0 op=5 SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)" conn=0 op=5 SRCH attr=hasSubordinates objectClass slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 ==> limits_get: conn=0 op=5 dn="uid=manager,dc=foo,dc=bar" [rw] searchDN: "dc=foo,dc=bar" -> "dc=foo,dc=bar,dc=foo,dc=bar" >>> dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar> <<< dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar>, <dc=foo,dc=bar,dc=foo,dc=bar> str2filter "(objectClass=*)" begin get_filter PRESENT end get_filter 0 => bdb_search bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar") => bdb_dn2id("dc=bar,dc=foo,dc=bar") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=0 op=5 p=3 send_ldap_result: err=10 matched="dc=foo,dc=bar" text="" [rw] matchedDN: "dc=foo,dc=bar" -> "" >>> dnPretty: <> <<< dnPretty: <> send_ldap_response: msgid=6 tag=101 err=32 conn=0 op=5 SEARCH RESULT tag=101 err=32 nentries=0 text= Nikos Pierangelo Masarati wrote: > nvoutsin(a)noc.uoa.gr wrote: >> While slapd does not segfault anymore, slapd insists to concatenate >> unrelated database suffixes during search operations that look for attrs >> such as hasSubordinates. >> >> I mention this here because it seems to be related somehow > > As I could see it working as expected (by me, at least), I suggest you > cook a very simple example, consisting in two slapd.conf (one for the > remote server, and one for the offending mixed local-proxy-relay setup), > and as many data in LDIF format and submit it, so that you can show what > you consider an incorrect behavior. Otherwise, I don't see any further > indication of a bug. > > 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#4976) memory corruption in test008-concurrency
by h.b.furuseth＠usit.uio.no 22 May '07

22 May '07

hyc(a)symas.com writes: > Try using ElectricFence, with my pthread patches. Still refuses to crash... -- Regards, Hallvard

1 0

Re: (ITS#4979) Bad response when requesting bad attributes
by hyc＠symas.com 22 May '07

22 May '07

Emmanuel Lecharny wrote: > Howard Chu a écrit : >> This works as designed - requesting an objectclass means to request >> all of the attributes included in that objectclass. In current >> revisions we expect objectClass names to be prefixed with "@" but the >> original behavior is still supported for backward compatibility. >> > Oh... Is there any RFC which expose this intended behaviour ? RFC 4529. This ITS will be closed. -- -- 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#4979) Bad response when requesting bad attributes
by hyc＠symas.com 22 May '07

22 May '07

elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.3.32 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.236.207.89) > > > When searching for entries using attributes to filter the result, you get all > the entries attributes if you give a wrong attribute : > > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" 9.9.9 > > will correctly returns only the DNs of all found entries, as if the 9.9.9 > attribute was 1.1 > > but > > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" person > > will return all entries attributes, as if the 'person' was substituted by "*" > > Of course, 'person' is not an attribute, but an objectClass, but the user intent > was to get only one single attribute value, so I don't think that returning > everything is correct. > > This is obviously not a serious issue. This works as designed - requesting an objectclass means to request all of the attributes included in that objectclass. In current revisions we expect objectClass names to be prefixed with "@" but the original behavior is still supported for backward compatibility. -- -- 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#4979) Bad response when requesting bad attributes
by elecharny＠apache.org 22 May '07

22 May '07

Hallvard B Furuseth a écrit : >elecharny(a)apache.org writes: > > >>ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b >>"dc=example,dc=com" -s sub "(objectClass=*)" person >> >>will return all entries attributes, as if the 'person' was substituted >>by "*" >> >> > >That is what RFC 4511 says. Section 4.5.1.8 (SearchRequest.attributes): > "If an attribute description in the list is not recognized, it is > ignored by the server." >Ignoring "person" yields an empty list, which works like a "*". > >I'm guessing that's not what it was intended to say though. RFC 1777 >(LDAPv2) did not have it, so 'person' would work like '1.1' does now. > > > Well, RFC 4511 just states that if the attribute is unknow, then it is ignored, but say nothing about using '1.1' or '*' . Ignoring the only attributes given by the user and substitute a '*' to it is a violation of user intent, IMHO (even if this user was wrong when selecting the attribute). RFC 4511 authors didn't thought of such a case, I guess ;) Anyway, OpenLdap behave differently if the attribute is unknown (9.9.9) and when it is known by the server (at least, the OID is known, even if it's not an attribute object), when it should returns always the same result : either '*' or '1.1'. This is not the case, and it's not consistent, whatever RFC 4511 says - or omits to say :) -. Emmanuel

1 0

Re: (ITS#4979) Bad response when requesting bad attributes
by h.b.furuseth＠usit.uio.no 22 May '07

22 May '07

elecharny(a)apache.org writes: > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" person > > will return all entries attributes, as if the 'person' was substituted > by "*" That is what RFC 4511 says. Section 4.5.1.8 (SearchRequest.attributes): "If an attribute description in the list is not recognized, it is ignored by the server." Ignoring "person" yields an empty list, which works like a "*". I'm guessing that's not what it was intended to say though. RFC 1777 (LDAPv2) did not have it, so 'person' would work like '1.1' does now. -- Regards, Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs