openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

RE: (ITS#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 17 Nov '08

17 Nov '08

I wouldn't say that it is harmless. To sum up, the problem is that when I modify frontend access control and then config access control (olcAccess attribute in both cases), I can not bind any more (neither with rootdn nor with any other dn). Concerning further releases, I will try later. Maybe I will wait for the 2.4.13... > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : dimanche 16 novembre 2008 22:01 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5805) Problem when modifying access control > > emmanuel.duru(a)atosorigin.com wrote: > > Full_Name: Emmanuel Duru > > Version: 2.4.11 > > OS: Windows > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (80.78.0.137) > > > > > > I have a single BDB database directory with root DN as a physical entry. > My > > access control is defined as follows in olcDatabase={-1}frontend: > > olcAccess: {0}to attrs=userPassword by self write by anonymous auth > by * no > > ne > > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > > olcAccess: {2}to * by self write by users read by anonymous read by > * none > > > > I perform a modify operation as follows: > > dn: olcDatabase={-1}frontend,cn=config > > changetype: modify > > replace: olcAccess > > olcAccess: {0}to attrs=userPassword by self write by anonymous auth > by * no > > ne > > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > > olcAccess: {2}to * by self write by users read by anonymous read by > * none > > > > dn: olcDatabase={0}config,cn=config > > changetype: modify > > replace: olcAccess > > olcAccess: {0}to * by * none > > - > > replace: olcRootDN > > olcRootDN: cn=manager,c=fr > > > > then I can not bind any more to the directory (invalid credentials). > > The log says (do notice the line dn: [1]... with non printable > characters): > > do_bind: version=3 dn="cn=manager,c=fr" method=128 > > ==> bdb_bind: dn: cn=manager,c=fr > > bdb_dn2entry("cn=manager,c=fr") > > => access_allowed: auth access to "cn=manager,c=fr" "userPassword" > requested > > => dn: [1] <some non printable characters>anager,c=fr > > => acl_get: [2] attr userPassword > > => slap_access_allowed: result not in cache (userPassword) > > => acl_mask: access to entry "cn=manager,c=fr", attr "userPassword" > requested > > => acl_mask: to value by "", (=0) > > <= check a_dn_pat: * > > <= acl_mask: [1] applying none(=0) (stop) > > <= acl_mask: [1] mask: none(=0) > > => slap_access_allowed: auth access denied by none(=0) > > => access_allowed: no more rules > > > > When I stop the directory, the log says (filter_free lines may vary): > > bdb_db_close: database "c=fr": alock_close failed > > filter_free: unknown filter type=20224 > > filter_free: unknown filter type=496 > > slapd stopped. > > filter_free: unknown filter type=29776 > > filter_free: unknown filter type=13944 > > filter_free: unknown filter type=29496 > > > > When I restart slapd, all is fine: the access control is OK and I can > bind. > > I can't confirm your report with HEAD code. I suggest you retry with > either 2.4.12 or (better) re24, which is about to be released as 2.4.13. > I note that by performing the operations you indicate, the cn=config > database (dn: olcDatabase={0}config,cn=config) ends up in an > inconsistent state, because the rootdn does not belong to its naming > context, but the rootpw is set, which should not be allowed. A check > for this does not exist, while it should. In any case, this is harmless. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > -----------------------------------

1 0

Posible bug with alias
by Alberto Gomez 17 Nov '08

17 Nov '08

Hi, I have found a possible bug on OpenLDAP when querying an entry which is an alias. This is the query: ldapsearch -x -h localhost -L -b "msisdn=911,dc=msisdn,ou=aliases,dc=mybasedn" -s subtree -a search # # LDAPv3 # base <msisdn=911,dc=msisdn,ou=aliases,dc=mybasedn> with scope subtre e # filter: (objectclass=*) # requesting: ALL # # 111, realentries, mybasedn dn: subsId=111,ou=realentries,dc=mybasedn objectClass: top objectClass: RealEntry subsId: 111 # 911, msisdn, aliases, mybasedn dn: MSISDN=911,dc=msisdn,ou=aliases,dc=mybasedn objectClass: top objectClass: alias objectClass: MSISDN MSISDN: 911 aliasedObjectName: subsId=111,ou=realentries,dc=mybasedn CDC: 0 usageCnt: 1 # search result # numResponses: 3 # numEntries: 2 What I would expect is the alias entry to be returned (as the derefAlias=search) but instead I get the alias entry and the aliased entry. I am using OpenLDAP 2.3.43-1 on cygwin. Is this a bug? Best regards, Alberto Gómez

1 0

Re: (ITS#5814) concurrent access to connections
by ando＠sys-net.it 16 Nov '08

16 Nov '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Hallvard B Furuseth wrote: >>> test036-meta-concurrency just crashed with fresh HEAD code. >>> I suppose that's the same as this ITS. >> Looks like. However, now I thought my FIXME were little more than a >> precaution. In fact, right now the only places where c_struct_state can >> be modified are protected by a mutex on connections_mutex; this should >> prevent changing the state of a connection during a connection_next() >> call. Do you see a thread waiting on >> ldap_pvt_thread_mutex_lock(&connections_mutex ); at connection.c:427 or >> connection.c:514? If that's the case, we probably need to move >> c->c_conn_state = SLAP_C_INACTIVE; inside the mutex in order to be able >> to safely assert in connection_next(). Is it worth? > > That should not be necessary. c_struct_state is supposed to be protected by > connections_mutex, while c_conn_state is supposed to be protected by > c->c_mutex. As already described in the comments at the top of the file. What seesm to happen is that c_conn_state is changed, then connections_mutex prevents from changing c_struct_state. As a consequence, connection_next() treats a connection structure based on its c_struct_state, which is now correctly protected, but then asserts on its c_conn_state, which has already been modified. So we are asserting on the state of a connection that is being modified, and is by design in a temporarily inconsistent state. Now things should be safe, though. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5814) concurrent access to connections
by hyc＠symas.com 16 Nov '08

16 Nov '08

ando(a)sys-net.it wrote: > Hallvard B Furuseth wrote: >> test036-meta-concurrency just crashed with fresh HEAD code. >> I suppose that's the same as this ITS. > > Looks like. However, now I thought my FIXME were little more than a > precaution. In fact, right now the only places where c_struct_state can > be modified are protected by a mutex on connections_mutex; this should > prevent changing the state of a connection during a connection_next() > call. Do you see a thread waiting on > ldap_pvt_thread_mutex_lock(&connections_mutex ); at connection.c:427 or > connection.c:514? If that's the case, we probably need to move > c->c_conn_state = SLAP_C_INACTIVE; inside the mutex in order to be able > to safely assert in connection_next(). Is it worth? That should not be necessary. c_struct_state is supposed to be protected by connections_mutex, while c_conn_state is supposed to be protected by c->c_mutex. As already described in the comments at the top of the file. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5814) concurrent access to connections
by h.b.furuseth＠usit.uio.no 16 Nov '08

16 Nov '08

Pierangelo Masarati writes: > Do you see a thread waiting on > ldap_pvt_thread_mutex_lock( &connections_mutex ); at connection.c:427 or > connection.c:514? Yes, thread 4: (gdb) thread apply all backtrace Thread 10 (process 8228): #0 0x00000038cf6075b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000042afa2 in slapd_daemon () at daemon.c:2656 #2 0x00000000004198c4 in main (argc=8, argv=0x7fff65271058) at main.c:948 Thread 9 (process 8245): #0 0x00000038cead1f58 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000042d2bb in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2291 #2 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 8 (process 8260): #0 0x00000038ceab8947 in sched_yield () from /lib64/libc.so.6 #1 0x00002acc4bb99bd0 in meta_back_search (op=0x14f7c4b0, rs=0x42f23ca0) at search.c:1542 #2 0x0000000000432276 in fe_op_search (op=0x14f7c4b0, rs=0x42f23ca0) at search.c:366 #3 0x0000000000432a07 in do_search (op=0x14f7c4b0, rs=0x42f23ca0) at search.c:217 #4 0x0000000000430331 in connection_operation (ctx=0x42f23df0, arg_v=<value optimized out>) at connection.c:1090 #5 0x000000000043077d in connection_read_thread (ctx=0x42f23df0, argv=<value optimized out>) at connection.c:1216 #6 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #7 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #8 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 7 (process 8261): #0 0x00000038ceac9016 in poll () from /lib64/libc.so.6 #1 0x00002acc4584d142 in ldap_result (ld=0x15815910, msgid=346, all=1, timeout=<value optimized out>, result=0x437249e8) at result.c:355 #2 0x00002acc4bb9afa8 in meta_back_op_result (mc=0x15815810, op=0x1507ca40, rs=0x43724ca0, candidate=1, msgid=346, timeout=0, sendok=LDAP_BACK_SENDRESULT) at bind.c:1004 #3 0x00002acc4bb9e731 in meta_back_modrdn (op=0x1507ca40, rs=0x43724ca0) at modrdn.c:141 #4 0x000000000044874a in fe_op_modrdn (op=0x1507ca40, rs=0x43724ca0) at modrdn.c:314 #5 0x00000000004491b4 in do_modrdn (op=0x1507ca40, rs=0x43724ca0) at modrdn.c:186 #6 0x0000000000430331 in connection_operation (ctx=0x43724df0, arg_v=<value optimized out>) at connection.c:1090 #7 0x000000000043077d in connection_read_thread (ctx=0x43724df0, argv=<value optimized out>) at connection.c:1216 #8 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #9 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #10 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 6 (process 8391): #0 0x00000038ceac9016 in poll () from /lib64/libc.so.6 #1 0x00002acc4584d142 in ldap_result (ld=0x1519d440, msgid=87, all=2, timeout=<value optimized out>, result=0x41b015f0) at result.c:355 #2 0x00002acc4bb9773c in meta_back_search (op=0x41b01640, rs=0x41b017b0) at search.c:1027 #3 0x00002acc4bba07a3 in meta_back_get_candidate (op=0x151c0b70, rs=0x41b01ca0, ndn=0x41b019a0) at conn.c:891 #4 0x00002acc4bba26fa in meta_back_getconn (op=0x151c0b70, rs=0x41b01ca0, candidate=0x0, sendok=LDAP_BACK_BINDING) at conn.c:1325 #5 0x00002acc4bb9c4cb in meta_back_bind (op=0x151c0b70, rs=0x41b01ca0) at bind.c:96 #6 0x000000000044b52e in fe_op_bind (op=0x151c0b70, rs=0x41b01ca0) at bind.c:383 #7 0x000000000044bf2f in do_bind (op=0x151c0b70, rs=0x41b01ca0) at bind.c:205 #8 0x0000000000430331 in connection_operation (ctx=0x41b01df0, arg_v=<value optimized out>) at connection.c:1090 #9 0x000000000043077d in connection_read_thread (ctx=0x41b01df0, argv=<value optimized out>) at connection.c:1216 #10 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #11 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #12 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 5 (process 8392): #0 0x00000038cf60c888 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038cf6088a5 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038cf608333 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00002acc4bdb2b57 in monitor_cache_lock (e=<value optimized out>) at cache.c:117 #4 0x00002acc4bdb1f9f in monitor_send_children (op=0x152cf4f0, rs=0x43f25ca0, e_parent=<value optimized out>, sub=1) at search.c:144 #5 0x00002acc4bdb2017 in monitor_send_children (op=0x152cf4f0, rs=0x43f25ca0, e_parent=<value optimized out>, sub=1) at search.c:123 #6 0x00002acc4bdb23a7 in monitor_back_search (op=0x152cf4f0, rs=0x43f25ca0) at search.c:245 #7 0x0000000000432276 in fe_op_search (op=0x152cf4f0, rs=0x43f25ca0) at search.c:366 #8 0x0000000000432a07 in do_search (op=0x152cf4f0, rs=0x43f25ca0) at search.c:217 #9 0x0000000000430331 in connection_operation (ctx=0x43f25df0, arg_v=<value optimized out>) at connection.c:1090 #10 0x000000000043077d in connection_read_thread (ctx=0x43f25df0, argv=<value optimized out>) at connection.c:1216 #11 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #12 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #13 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 4 (process 8393): #0 0x00000038cf60c888 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00000038cf6088a5 in _L_mutex_lock_107 () from /lib64/libpthread.so.0 #2 0x00000038cf608333 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0000000000431775 in connection_init (s=31, listener=0x14e3b280, dnsname=0x4c39b5 "unknown", peername=0x447258a0 "IP=127.0.0.1:50895", flags=0, ssf=0, authid=0x0) at connection.c:514 #4 0x000000000042b40a in slap_listener_thread (ctx=<value optimized out>, ptr=<value optimized out>) at daemon.c:1965 #5 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #6 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #7 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 3 (process 8395): #0 0x00000038ceac9016 in poll () from /lib64/libc.so.6 #1 0x00002acc4584d142 in ldap_result (ld=0x152cda90, msgid=529, all=2, timeout=<value optimized out>, result=0x44f275f0) at result.c:355 #2 0x00002acc4bb9773c in meta_back_search (op=0x44f27640, rs=0x44f277b0) at search.c:1027 #3 0x00002acc4bba07a3 in meta_back_get_candidate (op=0x154d8a90, rs=0x44f27ca0, ndn=0x44f279a0) at conn.c:891 #4 0x00002acc4bba26fa in meta_back_getconn (op=0x154d8a90, rs=0x44f27ca0, candidate=0x0, sendok=LDAP_BACK_BINDING) at conn.c:1325 #5 0x00002acc4bb9c4cb in meta_back_bind (op=0x154d8a90, rs=0x44f27ca0) at bind.c:96 #6 0x000000000044b52e in fe_op_bind (op=0x154d8a90, rs=0x44f27ca0) at bind.c:383 #7 0x000000000044bf2f in do_bind (op=0x154d8a90, rs=0x44f27ca0) at bind.c:205 #8 0x0000000000430331 in connection_operation (ctx=0x44f27df0, arg_v=<value optimized out>) at connection.c:1090 #9 0x000000000043077d in connection_read_thread (ctx=0x44f27df0, argv=<value optimized out>) at connection.c:1216 #10 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #11 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #12 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 2 (process 8497): #0 0x00000038cf60a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002acc4584a1f8 in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:654 #2 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000038cead1b6d in clone () from /lib64/libc.so.6 Thread 1 (process 8498): #0 0x00000038cea30155 in raise () from /lib64/libc.so.6 #1 0x00000038cea31bf0 in abort () from /lib64/libc.so.6 #2 0x00000038cea295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000431122 in connection_next (c=0x2acc4bfcad90, index=0x45f28a7c) at connection.c:877 #4 0x00002acc4bdb774f in monitor_subsys_conn_update (op=<value optimized out>, rs=<value optimized out>, e=0x14f10c88) at conn.c:230 #5 0x00002acc4bdb39cb in monitor_entry_update (op=0x2024, rs=0x45f29ca0, e=0x6) at entry.c:59 #6 0x00002acc4bdb1fd0 in monitor_send_children (op=0x15714210, rs=0x45f29ca0, e_parent=0x14f10c88, sub=1) at search.c:88 #7 0x00002acc4bdb2017 in monitor_send_children (op=0x15714210, rs=0x45f29ca0, e_parent=<value optimized out>, sub=1) at search.c:123 #8 0x00002acc4bdb23a7 in monitor_back_search (op=0x15714210, rs=0x45f29ca0) at search.c:245 #9 0x0000000000432276 in fe_op_search (op=0x15714210, rs=0x45f29ca0) at search.c:366 #10 0x0000000000432a07 in do_search (op=0x15714210, rs=0x45f29ca0) at search.c:217 #11 0x0000000000430331 in connection_operation (ctx=0x45f29df0, arg_v=<value optimized out>) at connection.c:1090 #12 0x000000000043077d in connection_read_thread (ctx=0x45f29df0, argv=<value optimized out>) at connection.c:1216 #13 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #14 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #15 0x00000038cead1b6d in clone () from /lib64/libc.so.6 (gdb) thread 4 (gdb) frame 3 #3 0x0000000000431775 in connection_init (s=31, listener=0x14e3b280, dnsname=0x4c39b5 "unknown", peername=0x447258a0 "IP=127.0.0.1:50895", flags=0, ssf=0, authid=0x0) at connection.c:514 514 ldap_pvt_thread_mutex_lock( &connections_mutex ); (gdb) p c $4 = (Connection *) 0x2acc4bfcad90 (gdb) p *c $5 = {c_struct_state = 1, c_conn_state = 1, c_conn_idx = 31, c_sd = 31, c_close_reason = 0x4c355a "?", c_mutex = {__data = {__lock = 1, __count = 0, __owner = 8393, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000É \000\000\001", '\0' <repeats 26 times>, __align = 1}, c_sb = 0x2aaab0009680, c_starttime = 1226874133, c_activitytime = 1226874133, c_connid = 46, c_peer_domain = {bv_len = 7, bv_val = 0x14f72e90 "unknown"}, c_peer_name = {bv_len = 18, bv_val = 0x1581ecc0 "IP=127.0.0.1:50895"}, c_listener = 0x14e3b280, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaea8}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaeb8}, c_write_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}, c_write_cv = {__data = {__lock = 0, __futex = 2, __total_seq = 1, __wakeup_seq = 1, __woken_seq = 1, __mutex = 0x2acc4bfcada8, __nwaiters = 0, __broadcast_seq = 0}, __size = "\000\000\000\000\002\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000šüKÌ*\000\000\000\000\000\000\000\000\000", __align = 8589934592}, c_currentber = 0x0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_txn = 0, c_txn_backend = 0x0, c_txn_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaf60}, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x441cb0 <slap_send_ldap_result>, c_send_search_entry = 0x43f700 <slap_send_search_entry>, c_send_search_reference = 0x43f050 <slap_send_search_reference>, c_send_ldap_extended = 0x441810 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x4416c0 <slap_send_ldap_intermediate>} -- Hallvard

1 0

Re: (ITS#5814) concurrent access to connections
by ando＠sys-net.it 16 Nov '08

16 Nov '08

Hallvard B Furuseth wrote: > test036-meta-concurrency just crashed with fresh HEAD code. > I suppose that's the same as this ITS. Looks like. However, now I thought my FIXME were little more than a precaution. In fact, right now the only places where c_struct_state can be modified are protected by a mutex on connections_mutex; this should prevent changing the state of a connection during a connection_next() call. Do you see a thread waiting on ldap_pvt_thread_mutex_lock( &connections_mutex ); at connection.c:427 or connection.c:514? If that's the case, we probably need to move c->c_conn_state = SLAP_C_INACTIVE; inside the mutex in order to be able to safely assert in connection_next(). Is it worth? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5814) concurrent access to connections
by h.b.furuseth＠usit.uio.no 16 Nov '08

16 Nov '08

test036-meta-concurrency just crashed with fresh HEAD code. I suppose that's the same as this ITS. #3 0x0000000000431122 in connection_next (c=0x2acc4bfcad90, index=0x45f28a7c) at connection.c:877 877 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (gdb) bt #0 0x00000038cea30155 in raise () from /lib64/libc.so.6 #1 0x00000038cea31bf0 in abort () from /lib64/libc.so.6 #2 0x00000038cea295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000431122 in connection_next (c=0x2acc4bfcad90, index=0x45f28a7c) at connection.c:877 #4 0x00002acc4bdb774f in monitor_subsys_conn_update (op=<value optimized out>, rs=<value optimized out>, e=0x14f10c88) at conn.c:230 #5 0x00002acc4bdb39cb in monitor_entry_update (op=0x2024, rs=0x45f29ca0, e=0x6) at entry.c:59 #6 0x00002acc4bdb1fd0 in monitor_send_children (op=0x15714210, rs=0x45f29ca0, e_parent=0x14f10c88, sub=1) at search.c:88 #7 0x00002acc4bdb2017 in monitor_send_children (op=0x15714210, rs=0x45f29ca0, e_parent=<value optimized out>, sub=1) at search.c:123 #8 0x00002acc4bdb23a7 in monitor_back_search (op=0x15714210, rs=0x45f29ca0) at search.c:245 #9 0x0000000000432276 in fe_op_search (op=0x15714210, rs=0x45f29ca0) at search.c:366 #10 0x0000000000432a07 in do_search (op=0x15714210, rs=0x45f29ca0) at search.c:217 #11 0x0000000000430331 in connection_operation (ctx=0x45f29df0, arg_v=<value optimized out>) at connection.c:1090 #12 0x000000000043077d in connection_read_thread (ctx=0x45f29df0, argv=<value optimized out>) at connection.c:1216 #13 0x00002acc4584a1aa in ldap_int_thread_pool_wrapper (xpool=0x14e6bce0) at tpool.c:663 #14 0x00000038cf6062f7 in start_thread () from /lib64/libpthread.so.0 #15 0x00000038cead1b6d in clone () from /lib64/libc.so.6 (gdb) p *index $2 = 31 (gdb) p connections[*index] $3 = {c_struct_state = 1, c_conn_state = 1, c_conn_idx = 31, c_sd = 31, c_close_reason = 0x4c355a "?", c_mutex = {__data = {__lock = 1, __count = 0, __owner = 8393, __nusers = 1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000É \000\000\001", '\0' <repeats 26 times>, __align = 1}, c_sb = 0x2aaab0009680, c_starttime = 1226874133, c_activitytime = 1226874133, c_connid = 46, c_peer_domain = {bv_len = 7, bv_val = 0x14f72e90 "unknown"}, c_peer_name = {bv_len = 18, bv_val = 0x1581ecc0 "IP=127.0.0.1:50895"}, c_listener = 0x14e3b280, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaea8}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaeb8}, c_write_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}, c_write_cv = {__data = {__lock = 0, __futex = 2, __total_seq = 1, __wakeup_seq = 1, __woken_seq = 1, __mutex = 0x2acc4bfcada8, __nwaiters = 0, __broadcast_seq = 0}, __size = "\000\000\000\000\002\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000šüKÌ*\000\000\000\000\000\000\000\000\000", __align = 8589934592}, c_currentber = 0x0, c_sasl_bind_in_progress = 0 '\0', c_writewaiter = 0 '\0', c_is_tls = 0 '\0', c_needs_tls_accept = 0 '\0', c_sasl_layers = 0 '\0', c_sasl_done = 0 '\0', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_txn = 0, c_txn_backend = 0x0, c_txn_ops = {stqh_first = 0x0, stqh_last = 0x2acc4bfcaf60}, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x441cb0 <slap_send_ldap_result>, c_send_search_entry = 0x43f700 <slap_send_search_entry>, c_send_search_reference = 0x43f050 <slap_send_search_reference>, c_send_ldap_extended = 0x441810 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x4416c0 <slap_send_ldap_intermediate>} -- Hallvard

1 0

(ITS#5815) typo in os-ip.c (MAXHOSTNAMELEN)
by h.b.furuseth＠usit.uio.no 16 Nov '08

16 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard #elif defined( MAXHOSTNAMELEN should be #elif defined( MAXHOSTNAMELEN ) Reported in Debian bug 505421. Fixing.

1 0

Re: (ITS#5805) Problem when modifying access control
by ando＠sys-net.it 16 Nov '08

16 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.4.11 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.78.0.137) > > > I have a single BDB database directory with root DN as a physical entry. My > access control is defined as follows in olcDatabase={-1}frontend: > olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no > ne > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > olcAccess: {2}to * by self write by users read by anonymous read by * none > > I perform a modify operation as follows: > dn: olcDatabase={-1}frontend,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * no > ne > olcAccess: {1}to dn=cn=manager,c=fr by self write by * none > olcAccess: {2}to * by self write by users read by anonymous read by * none > > dn: olcDatabase={0}config,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0}to * by * none > - > replace: olcRootDN > olcRootDN: cn=manager,c=fr > > then I can not bind any more to the directory (invalid credentials). > The log says (do notice the line dn: [1]... with non printable characters): > do_bind: version=3 dn="cn=manager,c=fr" method=128 > ==> bdb_bind: dn: cn=manager,c=fr > bdb_dn2entry("cn=manager,c=fr") > => access_allowed: auth access to "cn=manager,c=fr" "userPassword" requested > => dn: [1] <some non printable characters>anager,c=fr > => acl_get: [2] attr userPassword > => slap_access_allowed: result not in cache (userPassword) > => acl_mask: access to entry "cn=manager,c=fr", attr "userPassword" requested > => acl_mask: to value by "", (=0) > <= check a_dn_pat: * > <= acl_mask: [1] applying none(=0) (stop) > <= acl_mask: [1] mask: none(=0) > => slap_access_allowed: auth access denied by none(=0) > => access_allowed: no more rules > > When I stop the directory, the log says (filter_free lines may vary): > bdb_db_close: database "c=fr": alock_close failed > filter_free: unknown filter type=20224 > filter_free: unknown filter type=496 > slapd stopped. > filter_free: unknown filter type=29776 > filter_free: unknown filter type=13944 > filter_free: unknown filter type=29496 > > When I restart slapd, all is fine: the access control is OK and I can bind. I can't confirm your report with HEAD code. I suggest you retry with either 2.4.12 or (better) re24, which is about to be released as 2.4.13. I note that by performing the operations you indicate, the cn=config database (dn: olcDatabase={0}config,cn=config) ends up in an inconsistent state, because the rootdn does not belong to its naming context, but the rootpw is set, which should not be allowed. A check for this does not exist, while it should. In any case, this is harmless. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5814) concurrent access to connections
by ando＠sys-net.it 16 Nov '08

16 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > There is code that accesses c_conn_state and c_struct_state while not adequately > mutex-protected. In most cases, this code basically consists in assertions, so > we risk a core dump because of an assertion on non-mutex protected data. This > is the case (as happened to me) of connection_next(). > > I have a fix for the case I noticed, with two unhandled asserts (marked with a > FIXME) because I'm not sure whether it's worth to add extra mutexes just to be > able to safely assert, or remove assertions. > > Committing the fix; there might be more. Please check. I noticed this while testing concurrency for re24; here is the relevant portion of the core dump: (gdb) bt #0 0x00483402 in __kernel_vsyscall () #1 0x00c9ad20 in raise () from /lib/libc.so.6 #2 0x00c9c631 in abort () from /lib/libc.so.6 #3 0x00c9416b in __assert_fail () from /lib/libc.so.6 #4 0x08084b80 in connection_next (c=0x0, index=0xb62e3d8c) at ../../../ldap-2.4-src/servers/slapd/connection.c:871 #5 0x081a810c in monitor_subsys_conn_update (op=0x8a145f0, rs=0xb62e5128, e=0x896632c) at ../../../../ldap-2.4-src/servers/slapd/back-monitor/conn.c:230 <snip> (gdb) f 4 #4 0x08084b80 in connection_next (c=0x0, index=0xb62e3d8c) at ../../../ldap-2.4-src/servers/slapd/connection.c:871 (gdb) p connections[*index] $1 = {c_struct_state = 2, c_conn_state = 1, c_conn_idx = 19, c_sd = 19, <snip> 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2008