- openldap-bugs - openldap.org

RE: (ITS#5805) Problem when modifying access control
by h.b.furuseth＠usit.uio.no 17 Nov '08

17 Nov '08

Please post your configuration (minus any passwords) so it's possible to test what you are doing. Makes for less guesswork too. -- Hallvard

1 0

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

17 Nov '08

I'm sorry, but I don't. cn=manager,c=fr was already the rootdn of config database (as well as rootdn of c=fr database) before doing the test, with no rootpw in the config database. My first test consisted in modifying both olcAccess and olcRootDn for all databases (if present) without changing any value (replacing the existing values with the same ones). Then I made another test, with olcAccess modifications only (on both frontend and config databases), and the problem still appears. It only appears if I modify olcAccess of both databases, and in this order: frontend then config. > > You do, since you modify the configuration using the cn=config rootdn in > order to modify itself, and set it to cn=manager,c=fr. So in the first > place you had a rootdn in cn=config, with a rootpw. And the > modification you posted did not remove the rootpw.

1 0

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

17 Nov '08

emmanuel.duru(a)atosorigin.com wrote: >> Emmanuel Duru wrote: >>> I wouldn't say that it is harmless. >> I'm not saying your problem is harmless. I'm saying that having a >> rootdn of cn=config that is not within cn=config but with the rootpw is >> a violation of slapd's configuration rules (when the rootdn is not >> within the naming context, it cannot have a rootpw set). >> > > But I don't. > My rootdn is cn=manager,c=fr which is a real entry in the c=fr database > (bdb) with the password in the entry and no rootpw neither in c=fr nor in > cn=config. You do, since you modify the configuration using the cn=config rootdn in order to modify itself, and set it to cn=manager,c=fr. So in the first place you had a rootdn in cn=config, with a rootpw. And the modification you posted did not remove the rootpw. 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#5805) Problem when modifying access control
by emmanuel.duru＠atosorigin.com 17 Nov '08

17 Nov '08

> Emmanuel Duru wrote: > > I wouldn't say that it is harmless. > > I'm not saying your problem is harmless. I'm saying that having a > rootdn of cn=config that is not within cn=config but with the rootpw is > a violation of slapd's configuration rules (when the rootdn is not > within the naming context, it cannot have a rootpw set). > But I don't. My rootdn is cn=manager,c=fr which is a real entry in the c=fr database (bdb) with the password in the entry and no rootpw neither in c=fr nor in cn=config.

1 0

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

17 Nov '08

Emmanuel Duru wrote: > I wouldn't say that it is harmless. I'm not saying your problem is harmless. I'm saying that having a rootdn of cn=config that is not within cn=config but with the rootpw is a violation of slapd's configuration rules (when the rootdn is not within the naming context, it cannot have a rootpw set). > 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... Fine. 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#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

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

16 Nov '08

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. p.

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by geert＠boskant.nl 16 Nov '08

16 Nov '08

------=_Part_45002_9684276.1226844472048 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, Nov 16, 2008 at 2:25 AM, Howard Chu <hyc(a)symas.com> wrote: > That is completely irrelevant. If a given site has a misconfigured DNS, > whether or not it uses integrity or privacy checks on the DNS service, it is > still misconfigured. My point was that even if your reverse DNS mappings are correct, this is not a sufficient base for canonicalization. as it would have to be secure too. Or would you consider a DNS setup without DNSSEC to be broken too? In that case 99% of all setups would be broken. To maximize interoperability and security, applications SHOULD provide > security > mechanisms with names that result from folding the user- entered name to > lowercase without performing any other modifications or canonicalization. > Wishful thinking; that recommendation is at least 15 years too late and the > majority of Kerberized software isn't going to change to accommodate it. Not everybody needs to do this at once. MIT Kerberos already supports multiple ways of canonicalizing, including reverse DNS and the Canonicalize bit. Applications can start supporting this one by one. > In the meantime, the arguments about secure DNS are pure red herrings: > 1. if your DNS has been hijacked, it's most likely that you'll be directed > to a rogue KDC first, so the question of which service you're talking to is > moot. Wrong. Kerberos protects against that. A rogue KDC would not have your secret key and therefore is unable to generate a correct ticket for you. This would get noticed immediately by the library and the handshake would be aborted. > 2. there's nothing to gain from directing you to a rogue service, since > if you managed to contact the legitimate KDC, you're going to have a service > ticket that can only be decoded by the legitimate service principal. > On the other hand, if the rogue service is actually a valid principal in > your trusted KDC's database, then you clearly have an administrative problem > in your KDC. > Ok, so let me show you a real attack scenario as it indeed requires one copromised server. Supose an attacker has compromised one system in a Kerberos realm that was running a Kerberos service. The attacker can now spoof reverse DNS based on any of the available methods, and use it to redirect any internal service to a service on his server. He now puts up a mock up of the original service on the comprimised server, and coaxes users into entering any data that he would only enter in the real service. He can use this data to expand his compromised systems. If you would use secure canonicalization, the above cannot happen. It limits the scope of a compromise to that server. Without security canonicalization this is basically all-or-nothing security which is bad. This patch attempts to provide a band-aid without actually solving the real > problem. It merely masks the problem temporarily, until it gets even worse. No. From a security point it limits the impact of a comprimise of one server in your environment. From other point of views it helps environments that use the current best practise albeit broken method of canonicalizing host name. > This request is akin to asking for "schemachecking off" to be resurrected. > This sort of feature is always requested because of an existing mistake, and > allowing it only compounds the mistake further. We should never make it > easier for admins to make and ignore mistakes. This analogy does not work. The proposed option provides the possibility to implement a recommendation from the Kerberos RFC. Where in the LDAP RFCs does it say that it is recommended to turn schemachecking off? Regards,Geert ------=_Part_45002_9684276.1226844472048 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, Nov 16, 2008 at 2:25 AM, Howard Chu <span dir="ltr"><<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>></span> wrote:<br><div class="gmail_quote"> <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> That is completely irrelevant. If a given site has a misconfigured DNS, whether or not it uses integrity or privacy checks on the DNS service, it is still misconfigured.</blockquote><div class="Ih2E3d"><br>My point was that even if your reverse DNS mappings are correct, this is not a sufficient base for canonicalization. as it would have to be secure too. Or would you consider a DNS setup without DNSSEC to be broken too? In that case 99% of all setups would be broken.<br> <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">   To maximize interoperability and security, applications SHOULD provide security<br>   mechanisms with names that result from folding the user- entered name to<br>   lowercase without performing any other modifications or canonicalization.<br> </blockquote> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Wishful thinking; that recommendation is at least 15 years too late and the majority of Kerberized software isn't going to change to accommodate it.</blockquote><div><br>Not everybody needs to do this at once. MIT Kerberos already supports multiple ways of canonicalizing, including reverse DNS and the Canonicalize bit. Applications can start supporting this one by one.<br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> In the meantime, the arguments about secure DNS are pure red herrings:<br>  1. if your DNS has been hijacked, it's most likely that you'll be directed to a rogue KDC first, so the question of which service you're talking to is moot.</blockquote><div><br>Wrong. Kerberos protects against that. A rogue KDC would not have your secret key and therefore is unable to generate a correct ticket for you. This would get noticed immediately by the library and the handshake would be aborted.<br>  <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">  2. there's nothing to gain from directing you to a rogue service, since if you managed to contact the legitimate KDC, you're going to have a service ticket that can only be decoded by the legitimate service principal.</blockquote> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>  On the other hand, if the rogue service is actually a valid principal in your trusted KDC's database, then you clearly have an administrative problem in your KDC.<br></blockquote><div><br>Ok, so let me show you a real attack scenario as it indeed requires one copromised server. Supose an attacker has compromised one system in a Kerberos realm that was running a Kerberos service. The attacker can now spoof reverse DNS based on any of the available methods, and use it to redirect any internal service to a service on his server. He now puts up a mock up of the original service on the comprimised server, and coaxes users into entering any data that he would only enter in the real service. He can use this data to expand his compromised systems.<br> <br>If you would use secure canonicalization, the above cannot happen. It limits the scope of a compromise to that server. Without security canonicalization this is basically all-or-nothing security which is bad.<br><br></div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> This patch attempts to provide a band-aid without actually solving the real problem. It merely masks the problem temporarily, until it gets even worse.</blockquote><div><br>No. From a security point it limits the impact of a comprimise of one server in your environment. From other point of views it helps environments that use the current best practise albeit broken method of canonicalizing host name. <br> </div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> This request is akin to asking for "schemachecking off" to be resurrected. This sort of feature is always requested because of an existing mistake, and allowing it only compounds the mistake further. We should never make it easier for admins to make and ignore mistakes.</blockquote> <div><br>This analogy does not work. The proposed option provides the possibility to implement a recommendation from the Kerberos RFC. Where in the LDAP RFCs does it say that it is recommended to turn schemachecking off?<br> <br>Regards,Geert</div></div><br> ------=_Part_45002_9684276.1226844472048--

1 0

(ITS#5813) limits with empty dn mostly do not work
by h.b.furuseth＠usit.uio.no 15 Nov '08

15 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: http://folk.uio.no/hbf/OpenLDAP/limits-empty.txt Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Limits set as limits dn.<exact/base/onelevel/subtree/children>="" ... are never used: - exact/base: it only matches the empty Bind DN, which in slapd means anonymous, for which limits_get() does not test dn.<exact/base>. - onelevel/subtree/children: limits_get() does not use these for the empty Bind DN, and it expects a non-empty Bind DNs to end with ",". Some cases above work with dn.this.foo instead of dn.foo. limits dn.regex="" works (equivalent to limits users). limits dn.group="" may work if the admin stuffs group members into the root DSE. (I haven't tested.) My preferred fixes: - For dn.this, fix the above since baseDN "" makes sense and dn.this is new anyway, so there is no backwards compatibility to worry about. - For dn.self, fail parsing of the limit cases above that do not work. Otherwise the dn.this change could invoke new functionality in existing configurations. We won't know what the admin meant with DN "" - did he mean to include anonymous? That is not an entry with a DN, but is stored in slapd and the Bind request as the empty DN. Also limits parsing vs. anonymous connections is dubious today anyway: dn.<anything>=* or dn.regex=.* are special-cased to match anonymous, while dn="" does not. Also dn.children=* should not match anonymous but does. So it seems to me that any cleanup should consist of first removing strange cases, and if anyone want them reintroduce them in a later branch with correct semantics. I enclose a suggested fix. Giving Pierangelo at least time to repond since he either agreed or disagreed with this in this message, I'm not sure which:-) http://www.openldap.org/lists/openldap-devel/200810/msg00116.html I knew there was an issue about these limits I had forgotten.

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 15 Nov '08

15 Nov '08

Geert Jansen wrote: > Well .. I don't think my patch qualifies as breaking software to work > with broken software. The patch allows OpenLDAP applications to use > alternative ways for name canonicalization. At this moment this is not > possible because OpenLDAP is hard coded to canonicalize names with > reverse DNS. This means I cannot use the option that MIT Kerberos > provides me to disable this (rdns = no), as host names have already been > reverse mapped by OpenLDAP before they are passed into Kerberos. > > I agree with you that reverse DNS should be correct. I just mentioned > the fact that many reverse DNS setups are broken as an example of why it > can be problematic. The fact that many environments are misconfigured is not a good reason to change the current behavior. > Another reason why canonicalization based on reverse > DNS is problematic is that it requires secure DNS to be secure. RFC4120 > mentions this: That is completely irrelevant. If a given site has a misconfigured DNS, whether or not it uses integrity or privacy checks on the DNS service, it is still misconfigured. > Implementations of Kerberos and protocols based on Kerberos MUST NOT > use insecure DNS queries to canonicalize the hostname components of > the service principal names (i.e., they MUST NOT use insecure DNS > queries to map one name to another to determine the host part of the > principal name with which one is to communicate). > The same RFC recommends in fact that applications do not canonicalize > host names at all: > > To maximize interoperability and security, applications SHOULD provide security > mechanisms with names that result from folding the user- entered name to > lowercase without performing any other modifications or canonicalization. Wishful thinking; that recommendation is at least 15 years too late and the majority of Kerberized software isn't going to change to accommodate it. In the meantime, the arguments about secure DNS are pure red herrings: 1. if your DNS has been hijacked, it's most likely that you'll be directed to a rogue KDC first, so the question of which service you're talking to is moot. 2. there's nothing to gain from directing you to a rogue service, since if you managed to contact the legitimate KDC, you're going to have a service ticket that can only be decoded by the legitimate service principal. On the other hand, if the rogue service is actually a valid principal in your trusted KDC's database, then you clearly have an administrative problem in your KDC. This patch attempts to provide a band-aid without actually solving the real problem. It merely masks the problem temporarily, until it gets even worse. This request is akin to asking for "schemachecking off" to be resurrected. This sort of feature is always requested because of an existing mistake, and allowing it only compounds the mistake further. We should never make it easier for admins to make and ignore mistakes. -- -- 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#5812) New option to disable SASL host canonicalization
by geert＠boskant.nl 15 Nov '08

15 Nov '08

------=_Part_39674_19690948.1226797622518 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, Nov 15, 2008 at 6:20 PM, Howard Chu <hyc(a)symas.com> wrote: > > Breaking more software to use it with already broken software is, in a > word, stupid. The standard practice for Kerberos requires you to have > consistent forward and reverse DNS lookups. Sysadmins who are afraid to > administer their software should either change their software or change > their jobs. Well .. I don't think my patch qualifies as breaking software to work with broken software. The patch allows OpenLDAP applications to use alternative ways for name canonicalization. At this moment this is not possible because OpenLDAP is hard coded to canonicalize names with reverse DNS. This means I cannot use the option that MIT Kerberos provides me to disable this (rdns = no), as host names have already been reverse mapped by OpenLDAP before they are passed into Kerberos. I agree with you that reverse DNS should be correct. I just mentioned the fact that many reverse DNS setups are broken as an example of why it can be problematic. Another reason why canonicalization based on reverse DNS is problematic is that it requires secure DNS to be secure. RFC4120 mentions this: Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). The same RFC recommends in fact that applications do not canonicalize host names at all: To maximize interoperability and security, applications SHOULD provide security mechanisms with names that result from folding the user- entered name to lowercase without performing any other modifications or canonicalization. My patch implements this behaviour, as an option. Regards, Geert ------=_Part_39674_19690948.1226797622518 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, Nov 15, 2008 at 6:20 PM, Howard Chu <span dir="ltr"><<a href="mailto:hyc@symas.com" target="_blank">hyc(a)symas.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> Breaking more software to use it with already broken software is, in a word, stupid. The standard practice for Kerberos requires you to have consistent forward and reverse DNS lookups. Sysadmins who are afraid to administer their software should either change their software or change their jobs.</blockquote> <div><br>Well .. I don't think my patch qualifies as breaking software to work with broken software. The patch allows OpenLDAP applications to use alternative ways for name canonicalization. At this moment this is not possible because OpenLDAP is hard coded to canonicalize names with reverse DNS. This means I cannot use the option that MIT Kerberos provides me to disable this (rdns = no), as host names have already been reverse mapped by OpenLDAP before they are passed into Kerberos.<br> <br>I agree with you that reverse DNS should be correct. I just mentioned the fact that many reverse DNS setups are broken as an example of why it can be problematic. Another reason why canonicalization based on reverse DNS is problematic is that it requires secure DNS to be secure. RFC4120 mentions this:<br> <br><pre> Implementations of Kerberos and protocols based on Kerberos MUST NOT<br> use insecure DNS queries to canonicalize the hostname components of<br> the service principal names (i.e., they MUST NOT use insecure DNS<br> queries to map one name to another to determine the host part of the<br> principal name with which one is to communicate). </pre><br>The same RFC recommends in fact that applications do not canonicalize host names at all:<br> <br><pre> To maximize interoperability and security, applications SHOULD provide security<br> mechanisms with names that result from folding the user- entered name to<br> lowercase without performing any other modifications or canonicalization.<br> </pre><br>My patch implements this behaviour, as an option.<br><br>Regards,<br>Geert</div></div><br> ------=_Part_39674_19690948.1226797622518--

1 0

RE: (ITS#5788) Search does not work with nested naming contexts
by h.b.furuseth＠usit.uio.no 15 Nov '08

15 Nov '08

I wrote: > "LDAP operations normally access only one database. However > databases that provide related naming contexts ("suffixes") may be > glued together with the /subordinate/ keyword. Some other features > such as access controls and the /translucent/ overlay can also > involve multiple databases." I've added similar text to slapd.conf.5, but didn't see a suitable place for it in slapd-config.5. (Except in olcSubordinate description itself, where it is already mentioned). Admin guide fix still needed. -- Hallvard

1 0

Re: (ITS#5812) New option to disable SASL host canonicalization
by hyc＠symas.com 15 Nov '08

15 Nov '08

geert(a)boskant.nl wrote: > Full_Name: Geert Jansen > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch > Submission from: (NULL) (12.230.186.195) > > > This is a resubmission of my earlier patch in [1]. I'm asking for this patch to > be included into OpenLDAP. > > The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host > name canonicalization using reverse DNS for the host name that is passed into > SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets > SASL do the canonicalization. The option is disabled by default. > > Kerberos requires a canonical host name to work. Traditionally, host name > canonicalization has been done using reverse DNS. However, this is problematic. > See the comment below from the MIT Kerberos source on this subject: > > /* XXX: This is *so* bogus. There are several cases where > this won't get us the canonical name of the host, but > this is what we've trained people to expect. We'll > probably fix it at some point, but let's try to > preserve the current behavior and only shake things up > once when it comes time to fix this lossage. */ > > Since some time MIT Kerberos has support for server-side canonicalization which > is an alternative for the DNS based scheme. By default it uses both, but with an > option "rdns = no", reverse DNS can be disabled. > > The use case for this is environments that do not have reverse DNS set up > correctly. Especially in Windows Active Directory environments this is very > common. Administrators are afraid to enable scavenging for their zones, and > therefore any server IP change will leave a stale PTR record in place. This > breaks reverse DNS based canonicalization if the IP adress is reassigned. Breaking more software to use it with already broken software is, in a word, stupid. The standard practice for Kerberos requires you to have consistent forward and reverse DNS lookups. Sysadmins who are afraid to administer their software should either change their software or change their jobs. -- -- 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

(ITS#5812) New option to disable SASL host canonicalization
by geert＠boskant.nl 15 Nov '08

15 Nov '08

Full_Name: Geert Jansen Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/geert-jansen-081115.patch Submission from: (NULL) (12.230.186.195) This is a resubmission of my earlier patch in [1]. I'm asking for this patch to be included into OpenLDAP. The patch adds an LDAP option called LDAP_OPT_X_SASL_NOCANON to disable host name canonicalization using reverse DNS for the host name that is passed into SASL. Instead, it passes verbatim the host name part from the LDAP URI and lets SASL do the canonicalization. The option is disabled by default. Kerberos requires a canonical host name to work. Traditionally, host name canonicalization has been done using reverse DNS. However, this is problematic. See the comment below from the MIT Kerberos source on this subject: /* XXX: This is *so* bogus. There are several cases where this won't get us the canonical name of the host, but this is what we've trained people to expect. We'll probably fix it at some point, but let's try to preserve the current behavior and only shake things up once when it comes time to fix this lossage. */ Since some time MIT Kerberos has support for server-side canonicalization which is an alternative for the DNS based scheme. By default it uses both, but with an option "rdns = no", reverse DNS can be disabled. The use case for this is environments that do not have reverse DNS set up correctly. Especially in Windows Active Directory environments this is very common. Administrators are afraid to enable scavenging for their zones, and therefore any server IP change will leave a stale PTR record in place. This breaks reverse DNS based canonicalization if the IP adress is reassigned. The behaviour enabled by this patch should remain optional and cannot become the default. It breaks the use case when multiple LDAP servers are load balanced using a CNAME record. [1] http://www.openldap.org/lists/openldap-devel/200710/msg00071.html

1 0

Re: (ITS#5807) build broken for solaris 9
by brett.maxfield＠gmail.com 15 Nov '08

15 Nov '08

------=_Part_31358_1557470.1226757706470 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline There's a path worth travelling, not. These are relatively old servers, but even assuming Sun could be made to care, which i doubt, thier solution would probably be to upgrade the server to sol10 / new hardware, and not provide a patch. But i think the solution is probably in autoconf detection somehow, i'll see if i can do something with autoconf/automake stuff. This is sol9 sparc with gcc from sunfreeware, so maybe the autoconf assumes solaris cc in parts, as gcc was not always around. I dont have any sparc gear presently to test on, i'll investigate next week.. On Sat, Nov 15, 2008 at 9:09 AM, Howard Chu <hyc(a)symas.com> wrote: > The Solaris 9 docs say otherwise. > > http://docs.sun.com/app/docs/doc/816-0214/6m6nf1omp?a=view#indexterm-646 > > >>> > If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, > the caller plans to use the returned socket address structure in a call to > bind(3SOCKET). > <<< > > We are using the flag correctly per the documentation, therefore I don't > believe this is an OpenLDAP bug. Take this up with Sun... > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > ------=_Part_31358_1557470.1226757706470 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <br>There's a path worth travelling, not. These are relatively old servers, but even assuming Sun could be made to care, which i doubt, thier solution would probably be to upgrade the server to sol10 / new hardware, and not provide a patch.<br> <br>But i think the solution is probably in autoconf detection somehow, i'll see if i can do something with autoconf/automake stuff. This is sol9 sparc with gcc from sunfreeware, so maybe the autoconf assumes solaris cc in parts, as gcc was not always around. <br> <br>I dont have any sparc gear presently to test on, i'll investigate next week..<br><br><div class="gmail_quote">On Sat, Nov 15, 2008 at 9:09 AM, Howard Chu <span dir="ltr"><<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The Solaris 9 docs say otherwise.<br> <br> <a href="http://docs.sun.com/app/docs/doc/816-0214/6m6nf1omp?a=view#indexterm-646" target="_blank">http://docs.sun.com/app/docs/doc/816-0214/6m6nf1omp?a=view#indexterm-646</a><br> <br> >>><br> If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, the caller plans to use the returned socket address structure in a call to bind(3SOCKET).<br> <<<<br> <br> We are using the flag correctly per the documentation, therefore I don't believe this is an OpenLDAP bug. Take this up with Sun...<br><font color="#888888"> -- <br>  -- Howard Chu<br>  CTO, Symas Corp.           <a href="http://www.symas.com" target="_blank">http://www.symas.com</a><br>  Director, Highland Sun     <a href="http://highlandsun.com/hyc/" target="_blank">http://highlandsun.com/hyc/</a><br>  Chief Architect, OpenLDAP  <a href="http://www.openldap.org/project/" target="_blank">http://www.openldap.org/project/</a><br> </font></blockquote></div><br> ------=_Part_31358_1557470.1226757706470--

1 0

Re: (ITS#5811) slapo-dds documentation
by ando＠sys-net.it 15 Nov '08

15 Nov '08

Emmanuel Dreyfus wrote: > Pierangelo Masarati <ando(a)sys-net.it> wrote: > >> So, was that the issue? > > Yes, and I just added it to the man page. Probably, slapo-dds should allow a different means to perform internal operations as a privileged user without requiring rootdn to be defined. This problem is common to many overlays (and features in general) that need to perform internal operations, like syncrepl. Documenting this requirement is fine by now, but the general problem persists. 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#5811) slapo-dds documentation
by manu＠netbsd.org 15 Nov '08

15 Nov '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > So, was that the issue? Yes, and I just added it to the man page. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org 15 Nov '08

15 Nov '08

Emmanuel Dreyfus <manu(a)netbsd.org> wrote: > I committed the modification: > http://www.openldap.org/lists/openldap-commit/200811/msg00303.html And this: http://www.openldap.org/lists/openldap-commit/200811/msg00302.html -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org 15 Nov '08

15 Nov '08

I committed the modification: http://www.openldap.org/lists/openldap-commit/200811/msg00303.html -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5811) slapo-dds documentation
by ando＠sys-net.it 15 Nov '08

15 Nov '08

manu(a)netbsd.org wrote: > Full_Name: Emmanuel Dreyfus > Version: HEAD > OS: NetBSD > URL: > Submission from: (NULL) (213.41.141.172) > > > slapo-dds(5) does not document that rootdn definition is mandatory for proper > function So, was that the issue? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5811) slapo-dds documentation
by manu＠netbsd.org 15 Nov '08

15 Nov '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD URL: Submission from: (NULL) (213.41.141.172) slapo-dds(5) does not document that rootdn definition is mandatory for proper function

1 0

Re: (ITS#5807) build broken for solaris 9
by hyc＠symas.com 14 Nov '08

14 Nov '08

brett.maxfield(a)gmail.com wrote: > Full_Name: Brett Maxfield > Version: 2.4.RELENG > OS: Solaris 9 (SunOS 2.9) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.18.108.167) > > > Hello, > > Trying to make tests for RE24 and 2.4.12 on solaris (SunOS 2.9) and getting a > failure : > > (build options - berkeleyDB previously installed with > --prefix=/usr/local/openldap24) > > export PATH=/usr/local/bin:/usr/ccs/bin:/usr/bin:/bin:/usr/sbin:/sbin > export LD_LIBRARY_PATH=/usr/local/openldap24/lib:/usr/local/ssl/lib:/usr/local/lib > CPPFLAGS="-I/usr/local/openldap24/include -I/usr/local/include" > LDFLAGS="-L/usr/local/openldap24/lib -L/usr/local/lib > -R/usr/local/openldap24/lib -R/usr/local/lib" ./configure --enable-shared > --enable-ssl --disable-ipv6 --with-threads --enable-slapd --enable-backends > --enable-overlays --disable-sql --disable-ndb --disable-slapi > > (result of make test, fails on the first test) > > # cat tests/testrun/slapd.1.log > @(#) $OpenLDAP: slapd 2.4.12 (Nov 13 2008 17:57:10) $ > testuser@myhost:/export/home/testuser/openldap24-build/openldap-2.4.12/servers/slapd > ldap_pvt_gethostbyname_a: host=myhost, r=0 > daemon_init: ldap://localhost:9011/ > daemon_init: listen on ldap://localhost:9011/ > daemon_init: 1 listeners to open... > ldap_url_parse_ext(ldap://localhost:9011/) > daemon: getaddrinfo() failed: invalid ai_flags > slapd stopped. > connections_destroy: nothing to destroy. > > ai_flags has to do with the options to listen/accept, and should be something > like NULL, it seemss sol9 does not like the AI_PASSIVE value. > > I manually changed it to šhints.ai_flags = NULL; // AI_PASSIVE;" > (servers/slapd/daemon.c line 1131) and the code compiles, and make test > succeeds. > > For solaris 9, hints.ai_flags should just use NULL. The Solaris 9 docs say otherwise. http://docs.sun.com/app/docs/doc/816-0214/6m6nf1omp?a=view#indexterm-646 >>> If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, the caller plans to use the returned socket address structure in a call to bind(3SOCKET). <<< We are using the flag correctly per the documentation, therefore I don't believe this is an OpenLDAP bug. Take this up with Sun... -- -- 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by hyc＠symas.com 14 Nov '08

14 Nov '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Pierangelo Masarati writes: >>>> I think ITS#5326 is related. Namely, write operations (add, rename) >>>> should always rebuild the (new)DN hierarchically from the tree. >>> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >>> needs to handle databases that are not that nice: We can't require >>> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >>> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >>> is an RFC (4533) so it should handle non-OpenLDAP peers. >> Syncrepl of course *handles* all of those cases. The only issue here is that >> our tests expect the results to be in a specific order, which is obviously an >> invalid requirement in the grand scheme of things. > I'm hitting an issue like this in some of the replication tests I'm > currently performing. For this purpose, I think we could hack > ldapsearch (or add a new prog, or use a script on ldapsearch output) > that sorts entries content attribute-wise and, within each attribute, > value-wise. Something like "sort" applied entry-wise after unwrapping > line folding, optionally case-insensitive would probably suffice. Hm, I already added that, when I was first putting back-ndb thru the test suite. In acfilter.sh, but currently only used for back-ndb too. At any rate, I've tweaked the consumer's rename detection code, so this specific ITS is now fixed. -- -- 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

Quanah Gibson-Mount wrote: >> I'm hitting an issue like this in some of the replication tests I'm >> currently performing. For this purpose, I think we could hack >> ldapsearch (or add a new prog, or use a script on ldapsearch output) >> that sorts entries content attribute-wise and, within each attribute, >> value-wise. Something like "sort" applied entry-wise after unwrapping >> line folding, optionally case-insensitive would probably suffice. > > I have a script somewhere from Matt Backes @ Symas that sorts LDIF > files. It was useful for seeing if it made any difference in slapadd (it > didn't). Well, if it were distributable, and written in a widely supported scripting language, it would be quite useful... 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by quanah＠zimbra.com 14 Nov '08

14 Nov '08

--On Friday, November 14, 2008 9:34 PM +0000 ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> Pierangelo Masarati writes: >>>> I think ITS#5326 is related. Namely, write operations (add, rename) >>>> should always rebuild the (new)DN hierarchically from the tree. >>> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >>> needs to handle databases that are not that nice: We can't require >>> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >>> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >>> is an RFC (4533) so it should handle non-OpenLDAP peers. >> >> Syncrepl of course *handles* all of those cases. The only issue here is >> that our tests expect the results to be in a specific order, which is >> obviously an invalid requirement in the grand scheme of things. > > > I'm hitting an issue like this in some of the replication tests I'm > currently performing. For this purpose, I think we could hack > ldapsearch (or add a new prog, or use a script on ldapsearch output) > that sorts entries content attribute-wise and, within each attribute, > value-wise. Something like "sort" applied entry-wise after unwrapping > line folding, optionally case-insensitive would probably suffice. I have a script somewhere from Matt Backes @ Symas that sorts LDIF files. It was useful for seeing if it made any difference in slapadd (it didn't). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Pierangelo Masarati writes: >>> I think ITS#5326 is related. Namely, write operations (add, rename) >>> should always rebuild the (new)DN hierarchically from the tree. >> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >> needs to handle databases that are not that nice: We can't require >> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >> is an RFC (4533) so it should handle non-OpenLDAP peers. > > Syncrepl of course *handles* all of those cases. The only issue here is that > our tests expect the results to be in a specific order, which is obviously an > invalid requirement in the grand scheme of things. I'm hitting an issue like this in some of the replication tests I'm currently performing. For this purpose, I think we could hack ldapsearch (or add a new prog, or use a script on ldapsearch output) that sorts entries content attribute-wise and, within each attribute, value-wise. Something like "sort" applied entry-wise after unwrapping line folding, optionally case-insensitive would probably suffice. 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by hyc＠symas.com 14 Nov '08

14 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> I think ITS#5326 is related. Namely, write operations (add, rename) >> should always rebuild the (new)DN hierarchically from the tree. > > I'm not sure what exactly the problem is, if any:-) Syncrepl itself > needs to handle databases that are not that nice: We can't require > that of back-perl, nor back-ldap which accesses a non-OpenLDAP server > (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl > is an RFC (4533) so it should handle non-OpenLDAP peers. Syncrepl of course *handles* all of those cases. The only issue here is that our tests expect the results to be in a specific order, which is obviously an invalid requirement in the grand scheme of things. > Still, if it keeps OpenLDAP-on-OpenLDAP clean, that's a plus. > Unless we want back-ldif to be different just to test that syncrepl > handles different backends. Might also make a test which replicates > between different backends - e.g. $BACKEND and back-ldif. The syncrepl rename-detection can be improved - we can compare the normalized parent DN, separately from the un-normalized RDN. This would eliminate a false detection of a move/rename solely due to superior RDNs being mismatched. -- -- 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#5810) $BACKEND selections in make test
by h.b.furuseth＠usit.uio.no 14 Nov '08

14 Nov '08

quanah(a)zimbra.com writes: > What about back-sql, back-ndb, etc? The test0* scripts don't seem to be really ported to other backends than bdb, hdb and ldbm, though I'm guessing about ndb. Back-sql has its own test scripts: tests/scripts/sql-*. acfilter.sh and run.in accomodate ndb a bit, but most of the $BACKEND tests are years old so I expect porting tests to ndb is in its infancy. Same with back-ldif and back-null, they will need help from acfilter.sh and some of the tests. Though there are a few tests for $BACKEND = ldif. -- Hallvard

1 0

Re: (ITS#5810) $BACKEND selections in make test
by quanah＠zimbra.com 14 Nov '08

14 Nov '08

--On Friday, November 14, 2008 3:38 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > A number of tests contain code like > if test "$BACKEND" != "bdb" && test "$BACKEND" != "hdb" ; then > echo "Test does not support $BACKEND" > exit 0 > fi > This looks like a holdover from ldbm, I suggest we remove it. What about back-sql, back-ndb, etc? I'm not sure it's just a holdover of ldbm. There's quite a few backends that may not support a number of things. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5810) $BACKEND selections in make test
by h.b.furuseth＠usit.uio.no 14 Nov '08

14 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard A number of tests contain code like if test "$BACKEND" != "bdb" && test "$BACKEND" != "hdb" ; then echo "Test does not support $BACKEND" exit 0 fi This looks like a holdover from ldbm, I suggest we remove it. Also tests for supported LDAP features chould exclude instead of include a backend. E.g. in test040-subtree-rename, replace case $BACKEND in hdb | ldif) ;; *) echo "subtree rename not supported by back-$BACKEND" exit 0 esac with case $BACKEND in bdb) echo "subtree rename not supported by back-$BACKEND" exit 0 esac Or possibly that shold be "... in bdb | ndb)", I don't know. Whoever knows can fix it either now or later:-) Also I'm not quite sure which of the tests that fail for back-ldif are supposed to. Back-null has no "directory" directive. To support it, tests/scripts/conf.sh could recognize a format like #!backend!...!backend!#config-line where the config-line is uncommented if $BACKEND is none of the backends. Thus, "#!null!#directory @TESTDIR@/db.1.a". Takes a backend list in case tests for other directoryless backends arrive. Finally I'll append " for ${BACKEND}" to the Starting/Running/Test completed output from tests/run and tests/scripts/all: run: echo "Running ${SCRIPT} for ${BACKEND}..." all: echo ">>>>> Executing all LDAP tests for ${BACKEND}" all: echo ">>>>> Starting ${TB}`basename $CMD`${TN} for ${BACKEND}..." all: echo ">>>>> $CMD completed ${TB}OK${TN} for ${BACKEND}." all: echo ">>>>> $CMD ${TB}failed${TN} for ${BACKEND} (exit $RC)"

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 14 Nov '08

14 Nov '08

Howard Chu wrote : >I ran your test and examined the logs. I don't think your test is valid. >Search for "not indexed" in the logs - you have not indexed the necessary >attributes, as recommended in the documentation. Hi Howard, Thank you for your testing. You are right about the indexes in the slave (the master indexes are OK). After adding the line : #bdb#index entryUUID,entryCSN eq to the slave's config file the problem persisted in the version checked ou on November 4. So I checked out the HEAD last night. The good news is that the problem is fixed now and every thing seems OK (six new modifications have been made to syncprov.c since Nov 2, one of which being made by Quanah and related to this issue). So the issue can be closed :-) Thanks again Best Regards Ali

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Pierangelo Masarati writes: >>> I think ITS#5326 is related. Namely, write operations (add, rename) >>> should always rebuild the (new)DN hierarchically from the tree. >> I'm not sure what exactly the problem is, if any:-) Syncrepl itself >> needs to handle databases that are not that nice: We can't require >> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server >> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl >> is an RFC (4533) so it should handle non-OpenLDAP peers. >> >> Still, if it keeps OpenLDAP-on-OpenLDAP clean, that's a plus. >> Unless we want back-ldif to be different just to test that syncrepl >> handles different backends. Might also make a test which replicates >> between different backends - e.g. $BACKEND and back-ldif. > > Agree to your objections. Though, ITS#5326 would improve OpenLDAP, IMHO :) Agree *with* your objections ... *implementing the feature proposed in* ITS#5326 ... 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> I think ITS#5326 is related. Namely, write operations (add, rename) >> should always rebuild the (new)DN hierarchically from the tree. > > I'm not sure what exactly the problem is, if any:-) Syncrepl itself > needs to handle databases that are not that nice: We can't require > that of back-perl, nor back-ldap which accesses a non-OpenLDAP server > (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl > is an RFC (4533) so it should handle non-OpenLDAP peers. > > Still, if it keeps OpenLDAP-on-OpenLDAP clean, that's a plus. > Unless we want back-ldif to be different just to test that syncrepl > handles different backends. Might also make a test which replicates > between different backends - e.g. $BACKEND and back-ldif. Agree to your objections. Though, ITS#5326 would improve OpenLDAP, IMHO :) 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by h.b.furuseth＠usit.uio.no 14 Nov '08

14 Nov '08

Pierangelo Masarati writes: > I think ITS#5326 is related. Namely, write operations (add, rename) > should always rebuild the (new)DN hierarchically from the tree. I'm not sure what exactly the problem is, if any:-) Syncrepl itself needs to handle databases that are not that nice: We can't require that of back-perl, nor back-ldap which accesses a non-OpenLDAP server (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl is an RFC (4533) so it should handle non-OpenLDAP peers. Still, if it keeps OpenLDAP-on-OpenLDAP clean, that's a plus. Unless we want back-ldif to be different just to test that syncrepl handles different backends. Might also make a test which replicates between different backends - e.g. $BACKEND and back-ldif. -- Hallvard

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by ando＠sys-net.it 14 Nov '08

14 Nov '08

I think ITS#5326 is related. Namely, write operations (add, rename) should always rebuild the (new)DN hierarchically from the tree. This might be expensive, and a pain for back-ldif, but would save lots of headaches and make entries always consistent. 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by h.b.furuseth＠usit.uio.no 14 Nov '08

14 Nov '08

I wrote: > A back-ldif entry file only contain the entry's RDN, not the DN. > (...) Yup, that was it. Different case in parent DNs. This: --- syncrepl.c 13 Nov 2008 21:46:49 -0000 1.421 +++ syncrepl.c 14 Nov 2008 09:29:30 -0000 @@ -3050,4 +3050,6 @@ dni->delOldRDN = 1; } + Debug( LDAP_DEBUG_TRACE, "<<::syncrepl rename:%s:%s:%d:>>\n", + rs->sr_entry->e_dn, dni->new_entry->e_dn, dni->delOldRDN ); /* A ModDN has happened, but other changes may have * occurred before we picked it up. So fallthru to shows these renames, with dni->delOldRDN = 1: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com cn=James A Jones 1,ou=alumni association,ou=people,dc=example,dc=com cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com cn=Barbara Jensen,ou=information technology division,ou=people,dc=example,dc=com Not sure what the right fix is. ldif_back_modrdn() receives op->orr_modlist already filled in with the cn="James A Jones 1" change. Just use the awk variant to sort the attribute values in tests/scripts/acfilter.sh? What happens with syncrepl between two servers that do not spell DNs the same - e.g. syncrepl from BDB to a backend which stores just the normalized DN? -- Hallvard

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by h.b.furuseth＠usit.uio.no 13 Nov '08

13 Nov '08

Sigh... > Thus a subtree search from the suffix ends up recursively > constructing the right DNs ...as far as back-ldif can know (parent DN of suffix can vary)... > but a search based further down does not. Good night:-) -- Hallvard

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by h.b.furuseth＠usit.uio.no 13 Nov '08

13 Nov '08

hyc(a)symas.com writes: > I think you need to check what back-ldif is > doing that triggers the false detection of a rename op. No time now, but I expect it's because of the following. From memory, I hope I get the details right: A back-ldif entry file only contain the entry's RDN, not the DN. The exact spelling of the suffix DN is not stored anywhere, except that of its RDN. And if you have stored the suffix entry "dc=NO" and add "dc=uio,dc=no", the lowercase in "dc=no" is lost. Furthermore the backend does not read parent and grandparent entries to construct the right DN. Instead it uses the baseDN of the request, though when it reads an entry it does replace the RDN with that from the entry file. Thus a subtree search from the suffix ends up recursively constructing the right DNs, but a search based further down does not. We could use the spelling of the suffix from slapd.conf's suffix. However that doesn't help operations with baseDN below the suffix, and unless we do read parent DNs it makes treatment of the suffix and other DNs inconsistent. Or we could cache all the DNs, but.. well, this is just back-ldif. -- Hallvard

1 0

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by hyc＠symas.com 13 Nov '08

13 Nov '08

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux >> URL: >> Submission from: (NULL) (129.240.6.233) >> Submitted by: hallvard >> >> >> With the latest back-ldif/ldif.c (rev 1.99), >> ./run -b ldif test048-syncrepl-multiproxy >> breaks with "master and P1 slave databases differ" and >> ./run -b ldif test018-syncreplication-persist >> when patched to not reject $BACKEND = ldif >> breaks with "producer and consumer databases differ". >> >> The offender is "rename to same DN" (ITS#5319), i.e. rev 1.99. >> Unless there is a big "duh!" in it, it exposed a syncrepl bug. > > Yes, thanks. The consumer assumed that an entry being renamed would have no > other modifications associated with it. This assumption is wrong. There are no > rename ops in test018, but apparently back-ldif is not returning the RDN with > the same case as the original entry, so syncrepl assumes a rename (that only > changed letter case) was done. > > Still looking at the fix. This is mostly fixed in HEAD. The diff still doesn't compare because some cn values are in the wrong order. I think you need to check what back-ldif is doing that triggers the false detection of a rename op. -- -- 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#5809) syncrepl + back-ldif + "rename to same DN" fails
by hyc＠symas.com 13 Nov '08

13 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > With the latest back-ldif/ldif.c (rev 1.99), > ./run -b ldif test048-syncrepl-multiproxy > breaks with "master and P1 slave databases differ" and > ./run -b ldif test018-syncreplication-persist > when patched to not reject $BACKEND = ldif > breaks with "producer and consumer databases differ". > > The offender is "rename to same DN" (ITS#5319), i.e. rev 1.99. > Unless there is a big "duh!" in it, it exposed a syncrepl bug. Yes, thanks. The consumer assumed that an entry being renamed would have no other modifications associated with it. This assumption is wrong. There are no rename ops in test018, but apparently back-ldif is not returning the RDN with the same case as the original entry, so syncrepl assumes a rename (that only changed letter case) was done. Still looking at the fix. -- -- 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#5788) Search does not work with nested naming contexts
by h.b.furuseth＠usit.uio.no 13 Nov '08

13 Nov '08

Reopening this as a doc bug. emmanuel.duru(a)atosorigin.com writes: > I'm sorry, but I am mainly working on Windows, and the use of man > pages is not that easy on Windows (or you would say Windows people are > not used to read man pages). The man pages are online too: http://www.openldap.org/software/man.cgi > Anyway, you could mention it in the admin guide. I agree. "What to do"-issue, belongs in the Guide. Though the manpages could be updated too, so a user who does't know to look for it has a better chance of learning it. Does this look right, as an addition under the "database" keyword in slapd.conf(5)? "LDAP operations normally access only one database. However databases that provide related naming contexts ("suffixes") may be glued together with the /subordinate/ keyword. Some other features such as access controls and the /translucent/ overlay can also involve multiple databases." BTW, the Guide's chapter 16 does say "... A better approach would be to use explicitly defined local and proxy databases in /subordinate/ configurations to provide a seamless view of the Distributed Directory." but it doesn't mention that this refers to the "subordinate" keyword - if it does. The rest of the "subordinates" in the guide do not. -- Hallvard

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 13 Nov '08

13 Nov '08

Ali Pouya wrote: > Howard Chu wrote : >> I don't see this happening on my builds. Maybe you should post your configs >> and a sample of the data and modifications used to illustrate the problem. > > > > Hi Howard, > I just uploaded the archive file ITS_5640.tar.gz to the OpenLdap FTP incoming directory. > The script test099-syncreplication-mirrormode of this archive, derived from the test018-syncreplication- > persist, reproduces the problem in the OpenLdap test environment. > To do so copy the file in the test directory of the openldap source, then : > > cd tests > tar xvzf ./ITS_5640.tar.gz > ./run test099-syncreplication-mirrormode > > Then look for the string 'access_allowed' in the log files. > This test shows that the problem has worsen : > > 1) The slave mirror does not scan only the recent objects but the whole tree, > 2) By sending a search with a specific control to the master it makes the master scan its whole tree as > well. > > This situation is reproduced each time you do a write operation in the master while the slave is down, and > then start the slave. > The tests have been done in the HEAD extracted on Tuesday November 4. I ran your test and examined the logs. I don't think your test is valid. Search for "not indexed" in the logs - you have not indexed the necessary attributes, as recommended in the documentation. -- -- 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#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 13 Nov '08

13 Nov '08

Howard Chu wrote : >I don't see this happening on my builds. Maybe you should post your configs >and a sample of the data and modifications used to illustrate the problem. Hi Howard, I just uploaded the archive file ITS_5640.tar.gz to the OpenLdap FTP incoming directory. The script test099-syncreplication-mirrormode of this archive, derived from the test018-syncreplication- persist, reproduces the problem in the OpenLdap test environment. To do so copy the file in the test directory of the openldap source, then : cd tests tar xvzf ./ITS_5640.tar.gz ./run test099-syncreplication-mirrormode Then look for the string 'access_allowed' in the log files. This test shows that the problem has worsen : 1) The slave mirror does not scan only the recent objects but the whole tree, 2) By sending a search with a specific control to the master it makes the master scan its whole tree as well. This situation is reproduced each time you do a write operation in the master while the slave is down, and then start the slave. The tests have been done in the HEAD extracted on Tuesday November 4. I hope this can help. Best Regards Ali

1 0

(ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
by h.b.furuseth＠usit.uio.no 13 Nov '08

13 Nov '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard With the latest back-ldif/ldif.c (rev 1.99), ./run -b ldif test048-syncrepl-multiproxy breaks with "master and P1 slave databases differ" and ./run -b ldif test018-syncreplication-persist when patched to not reject $BACKEND = ldif breaks with "producer and consumer databases differ". The offender is "rename to same DN" (ITS#5319), i.e. rev 1.99. Unless there is a big "duh!" in it, it exposed a syncrepl bug. It's unrelated to the other recent back-ldif patches: 1.98 passes these tests, as does 1.87, while 1.87 + a "rename to same DN" patch breaks. Rev 1.99 passes test005-modrdn & test040-subtree-rename. Another strange thing I've seen recently is that bash once in a while complains something like ./scripts/test018-syncreplication-persist: line 361: echo: write error: Interrupted system call This is indeed just an "echo" statement in the test script: echo "Comparing retrieved entries from producer and consumer..." Don't know what's going on or if it's relatead, but I've not seen (or noticed) it before.

1 0

(ITS#5808) jldap library connect timeout doesn't work
by mavricknzwork＠yahoo.com 13 Nov '08

13 Nov '08

Full_Name: Matt Stevenson Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.129.121.62) I believe trying to timeout using "LDAPConnection(int timeout)" will not work. The below patch fixes that, with limited testing. Regards Matt I, Matt Stevenson, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. ### Eclipse Workspace Patch 1.0 #P jldap Index: com/novell/ldap/Connection.java =================================================================== RCS file: /repo/OpenLDAP/pkg/jldap/com/novell/ldap/Connection.java,v retrieving revision 1.91 diff -u -r1.91 Connection.java --- com/novell/ldap/Connection.java 22 Feb 2008 11:29:50 -0000 1.91 +++ com/novell/ldap/Connection.java 13 Nov 2008 11:22:30 -0000 @@ -21,7 +21,7 @@ import java.net.Socket; import java.net.SocketException; import java.net.SocketTimeoutException; - +import java.net.InetSocketAddress; import com.novell.ldap.asn1.*; import com.novell.ldap.client.*; @@ -454,7 +454,10 @@ } socket = mySocketFactory.createSocket(host, port); } else { - socket = new Socket(host, port); + socket = new Socket(); + InetSocketAddress socketAddress = new InetSocketAddress(host, port); + socket.connect(socketAddress, myTimeOut); + //socket = new Socket(host, port); if(myTimeOut > 0) { socket.setSoTimeout(myTimeOut);

1 0

RE: (ITS#5788) Search does not work with nested naming contexts
by emmanuel.duru＠atosorigin.com 13 Nov '08

13 Nov '08

I'm sorry, but I am mainly working on Windows, and the use of man pages is not that easy on Windows (or you would say Windows people are not used to read man pages). Anyway, you could mention it in the admin guide. > -----Message d'origine----- > De : Gavin Henry [mailto:ghenry@OpenLDAP.org] > Envoyé : mercredi 12 novembre 2008 17:38 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5788) Search does not work with nested naming contexts > > emmanuel.duru(a)atosorigin.com wrote: > > OK, thank you. > > I didn't see this configuration directive in the admin guide... > > All the details are always in the man pages. > > Cheers. > > -- > Kind Regards, > > Gavin Henry. > OpenLDAP Engineering Team. > > E ghenry(a)OpenLDAP.org > > Community developed LDAP software. > > http://www.openldap.org/project/

1 0

(ITS#5807) build broken for solaris 9
by brett.maxfield＠gmail.com 13 Nov '08

13 Nov '08

Full_Name: Brett Maxfield Version: 2.4.RELENG OS: Solaris 9 (SunOS 2.9) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.18.108.167) Hello, Trying to make tests for RE24 and 2.4.12 on solaris (SunOS 2.9) and getting a failure : (build options - berkeleyDB previously installed with --prefix=/usr/local/openldap24) export PATH=/usr/local/bin:/usr/ccs/bin:/usr/bin:/bin:/usr/sbin:/sbin export LD_LIBRARY_PATH=/usr/local/openldap24/lib:/usr/local/ssl/lib:/usr/local/lib CPPFLAGS="-I/usr/local/openldap24/include -I/usr/local/include" LDFLAGS="-L/usr/local/openldap24/lib -L/usr/local/lib -R/usr/local/openldap24/lib -R/usr/local/lib" ./configure --enable-shared --enable-ssl --disable-ipv6 --with-threads --enable-slapd --enable-backends --enable-overlays --disable-sql --disable-ndb --disable-slapi (result of make test, fails on the first test) # cat tests/testrun/slapd.1.log @(#) $OpenLDAP: slapd 2.4.12 (Nov 13 2008 17:57:10) $ testuser@myhost:/export/home/testuser/openldap24-build/openldap-2.4.12/servers/slapd ldap_pvt_gethostbyname_a: host=myhost, r=0 daemon_init: ldap://localhost:9011/ daemon_init: listen on ldap://localhost:9011/ daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://localhost:9011/) daemon: getaddrinfo() failed: invalid ai_flags slapd stopped. connections_destroy: nothing to destroy. ai_flags has to do with the options to listen/accept, and should be something like NULL, it seemss sol9 does not like the AI_PASSIVE value. I manually changed it to šhints.ai_flags = NULL; // AI_PASSIVE;" (servers/slapd/daemon.c line 1131) and the code compiles, and make test succeeds. For solaris 9, hints.ai_flags should just use NULL. Cheers Brett

1 0

(ITS#5806) slapo-syncprov man page and syncprov-sessionlog
by ghenry＠OpenLDAP.org 12 Nov '08

12 Nov '08

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry It is not clear that the "sessionlog" is actually stored in memory and not a phyiscal file: syncprov-sessionlog <ops> Specify a session log for recording information about write operations made on the database. The <ops> specifies the number of operations that are recorded in the log. All write operations (except Adds) are recorded in the log. When using the session log, it is helpful to set an eq index on the entryUUID attribute in the underlying database. It should be changed to read something like: "Configures an in-memory session log for recording information about write operations made on the database."

1 0

Re: (ITS#5788) Search does not work with nested naming contexts
by ghenry＠OpenLDAP.org 12 Nov '08

12 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > OK, thank you. > I didn't see this configuration directive in the admin guide... All the details are always in the man pages. Cheers. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

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

12 Nov '08

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.

1 0

(ITS#5804) attribute value regex expantion
by manu＠netbsd.org 11 Nov '08

11 Nov '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD URL: ftp://ftp.openldap.org/incoming/manu-20081111.patch Submission from: (NULL) (213.41.141.172) The attached patch allow substitution from attribut value regex. For instance: access to attrs=foo val.regex="^(.*)$" by dn.exact,expand="uid=${v1},o=home" write by * read stop ${v1} ${v2} ${v3} ... get the substitutions from attribute value regex ${d1} ${d2} ${d3} ... are aliases for $1 $2 $3 ... and get substitution from DN regex

1 0

ITS 5709
by Burton, Kris - Acision 11 Nov '08

11 Nov '08

All, I apologize if this is sent twice, I noticed I copied the wrong address in the first email sent by accident to openldap-its(a)openldap.org<mailto:openldap-its@openldap.org>. I am currently experiencing the problem that is detailed in ITS 5709. I am running OpenLDAP 2.4.11, from the information in ITS5709 it appears that this problem is resolved in HEAD. What I would like to do is to isolate the code that resolves this problem and put them in the 2.4.11 version of OpenLDAP that I am running. I have been trying to determine exactly what changes were added to resolve the issue. I also wanted to ask if doing this would be a viable solution until the time that another OpenLDAP version is released that resolves this issue. I am not familiar with the code base and would not want to introduce one change to try to resolve this issue and open up several new issues. Can someone familiar with the fix point me in the right direction as to whether the fix that resolves this is isolated and would be safe to back port to an older release (2.4.11), and if so how would I identify exactly what needs to be changed? Also if someone could inform me if the above ITS would be included in part of 2.4.13 and is there any projected date for when 2.4.13 would be released. Kris Burton Software Engineer ________________________________________ Acision. Innovation. Assured. www.acision.com 4870 Sadler Road Suite 200 Glen Allen, VA 23060 USA This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: (ITS#5796) back-sql intermittently failing
by robb＠wtg.cw.com 11 Nov '08

11 Nov '08

Pierangelo Masarati wrote: > OK, this makes sense. In fact, back-sql does not seem to specifically > handle broken connections to the odbc. It appears it would need > something similar to idle-timeout as in back-ldap and back-meta. ok, this looks like it... Nov 11 17:01:38 nops slapd[24733]: backsql_dn2id("dc=sql,dc=example,dc=com") : error executing query ("SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?", "dc=sql,dc=example,dc=com"): Nov 11 17:01:38 nops slapd[24733]: Return code: -1 Nov 11 17:01:38 nops slapd[24733]: nativeErrCode=2006 SQLengineState=08S01 msg="[unixODBC][MySQL][ODBC 3.51 Driver][mysqld-5.0.67-log]MySQL server has gone away" Nov 11 17:01:38 nops slapd[24733]: <==backsql_dn2id("dc=sql,dc=example,dc=com") : err=80 if you'd like a tarball of full logs + config just say. Regards, Rob

1 0

(ITS#5803) Incorrect filters (e.g. substrings) may trigger "disconnect"
by ando＠sys-net.it 11 Nov '08

11 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando When a malformed filter is encountered, ber decoding may stop before the specific element has been parsed. This results in a decoding error later, that triggers a "disconnect" response. To reproduce: search with "(objectClass=foo*bar)". The correct behavior would consist in parsing the whole filter anyway and identify it as COMPUTED UNDEFINED. p.

1 0

Re: (ITS#5796) back-sql intermittently failing
by ando＠sys-net.it 11 Nov '08

11 Nov '08

Robert Brooks wrote: > Pierangelo Masarati wrote: >> I have no possibility to setup a back-sql with mysql right now. Can >> you post your configuration? Can you post some (verbose) logs of >> operations affecting back-sql (e.g. with BACKSQL_TRACE manually >> #defined in back-sql/back-sql.h)? Can you step thru a search into >> backsql_search() and see if it gets called and why it doesn't get to >> contacting the rdbms? > > I'm compiling with BACKSQL_TRACE defined right now. > > After further prodding I have discovered... > > ejabberd (a jabber daemon) makes connections to ldap, which it keeps > open indefinitely. It appears mysql's odbc connector will time out an > idle mysql connection after 8 hours. Since this is the slave system it's > entirely possible for it not touch mysql connections for at least 8 hours. > > If we restart mysql some ldap queries fail on back-sql portion until we > kill ejabberd (to close it's ldap connections). > > I'll give you logs with tracing enabled asap, but this looks like a big > clue as to what is happening. OK, this makes sense. In fact, back-sql does not seem to specifically handle broken connections to the odbc. It appears it would need something similar to idle-timeout as in back-ldap and back-meta. 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#5796) back-sql intermittently failing
by robb＠wtg.cw.com 11 Nov '08

11 Nov '08

Pierangelo Masarati wrote: > I have no possibility to setup a back-sql with mysql right now. Can you > post your configuration? Can you post some (verbose) logs of operations > affecting back-sql (e.g. with BACKSQL_TRACE manually #defined in > back-sql/back-sql.h)? Can you step thru a search into backsql_search() > and see if it gets called and why it doesn't get to contacting the rdbms? I'm compiling with BACKSQL_TRACE defined right now. After further prodding I have discovered... ejabberd (a jabber daemon) makes connections to ldap, which it keeps open indefinitely. It appears mysql's odbc connector will time out an idle mysql connection after 8 hours. Since this is the slave system it's entirely possible for it not touch mysql connections for at least 8 hours. If we restart mysql some ldap queries fail on back-sql portion until we kill ejabberd (to close it's ldap connections). I'll give you logs with tracing enabled asap, but this looks like a big clue as to what is happening.

1 0

Re: (ITS#5796) back-sql intermittently failing
by ando＠sys-net.it 11 Nov '08

11 Nov '08

robb(a)wtg.cw.com wrote: > Full_Name: Robert Brooks > Version: 2 > OS: 2.4.12 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.49.19.14) > > > Set up is a pair of centos 4 hosts, one acts as primary, the other is a syncrepl > consumer and mysql slave. Apart from syncrepl config/myqsl slave all config and > software versions are the same. Mysql queries on both hosts are to localhost via > socket. > > After a period of operation (24-48 hours) the slave host drops the back-sql part > of directory for some queries (same query will suceed some times). Using strace > it can been seen that the ldap searches are not resulting in queries to mysql. > Back-sql is a subordinate db and results from hdb backed part of directory are > returned. > > Restarting slapd fixes the problem, but start-up reports the shutdown was > unclean on hdb db. Operation of primary is reliable. I have no possibility to setup a back-sql with mysql right now. Can you post your configuration? Can you post some (verbose) logs of operations affecting back-sql (e.g. with BACKSQL_TRACE manually #defined in back-sql/back-sql.h)? Can you step thru a search into backsql_search() and see if it gets called and why it doesn't get to contacting the rdbms? 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

[Fwd: ITS#4556 ACLs for new entries]
by hyc＠symas.com 11 Nov '08

11 Nov '08

For completeness' sake... ACL checking for Added entries is available in RE24/HEAD. See the add_content_acl / olcAddContentAcl setting in slapd.conf/slapd.d. The default for most DBs is off, for backward compatibility. It is ON by default for cn=config. -------- Original Message -------- Subject: ITS#4556 ACLs for new entries Date: Fri, 21 Sep 2007 09:00:37 -0700 From: Howard Chu <hyc(a)symas.com> To: OpenLDAP Devel <openldap-devel(a)openldap.org> Revisiting this topic - DITStructureRules are not a solution to this problem. E.g. in cn=config, now that you can grant write access to arbitrary users, it becomes pretty critical to be able to prevent certain users from creating certain types of objects. E.g., I may want to allow someone to be able to create one type of child object under cn=config (e.g., databases) but not some other type (e.g., modules). So at the very least we need to be able to use ACL filters on new entries. -- -- 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

(ITS#5796)
by robb＠webtechnologygroup.co.uk 11 Nov '08

11 Nov '08

can re-create this problem by restarting mysql. Following a restart about one in five queries fails on back-sql portion of directory.

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by quanah＠zimbra.com 10 Nov '08

10 Nov '08

--On Tuesday, November 11, 2008 3:52 AM +0000 abartlet(a)samba.org wrote: > > --=-nSmbtQnR20QHrM5OsFp5 > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: >> A tentative implementation is in HEAD, please test. You need to: > > I just wanted to say thankyou very much for doing this. The Samba side > of things has taken far longer than I ever imagined, but I hope to look > at the OpenLDAP integration this or next week. It was added to RE24 today, for inclusion in 2.4.13, so getting feedback would be great. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 10 Nov '08

10 Nov '08

--=-nSmbtQnR20QHrM5OsFp5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > A tentative implementation is in HEAD, please test. You need to: I just wanted to say thankyou very much for doing this. The Samba side of things has taken far longer than I ever imagined, but I hope to look at the OpenLDAP integration this or next week. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com --=-nSmbtQnR20QHrM5OsFp5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJGQF+z4A8Wyi0NrsRAnpXAJ9c4Lx4uVyadLTvaTaAm7rvTWKC+QCgrK9p Vhadna7DXcJs0h11JPmkg8c= =HgJ+ -----END PGP SIGNATURE----- --=-nSmbtQnR20QHrM5OsFp5--

1 0

Re: (ITS#5797) build failed
by hyc＠symas.com 10 Nov '08

10 Nov '08

cycwj(a)163.com wrote: > Full_Name: bluewind > Version: 2.4.12 > OS: ubunt server 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (219.133.134.8) > > > try to build on ubutnu server 8, use install manaul from www.openldap.org > > #./configure (ok) > #make depen (ok) > #make (ok) > > but,when execution > > #make test > > the system stop on "Running slapadd to build slapd database...", no any > response > > after about 1 hour I think what Ando was trying to say very subtly is that your bug report does not contain much useful information, and you should have searched the ITS for similar issues before posting. This is a known bug in BerkeleyDB 4.7.25. We have to guess that this is the version of BDB that you're using because you didn't provide this info in your report. ITS#5707 already contains the details of this bug and the official patch from Oracle. The patch is also present in the OpenLDAP CVS. This ITS will be closed. -- -- 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#5799) smbk5pwd update to work with heimdal 1.2 API
by hyc＠symas.com 10 Nov '08

10 Nov '08

admin(a)dmarkey.com wrote: > Full_Name: David Markey > Version: 2.4 > OS: Solaris/AIX/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.97.241.103) > > > Update smbk5pwd to work with the heimdal 1.2 API. Work has been done on the > mailing list but the patches have not been applied to the release. I don't see any patches in your report. Patches that are to be considered for inclusion into the codebase must be submitted to the ITS by their authors, with any Rights statement as needed. -- -- 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

(ITS#5796)
by robb＠webtechnologygroup.co.uk 10 Nov '08

10 Nov '08

strace from failing slapd process 13637 send(3, "<167>Nov 5 10:34:39 slapd[13628"..., 117, MSG_NOSIGNAL) = 117 13637 semop(22052874, 0xb53ad7d0, 2) = 0 13637 semop(22052874, 0xb53ad7e0, 1) = 0 13637 time(NULL) = 1225881279 13637 semop(22052874, 0xb53ad750, 2) = 0 13637 semop(22052874, 0xb53ad760, 1) = 0 13637 write(57, "\27\3\1\0 \334@\'\353]R\251-Q\251Dd>0\376&\227\326\4\222dU\t\266/\356\177"..., 90) = 90 13637 time(NULL) = 1225881279 13637 stat64("/etc/localtime", {st_dev=makedev(3, 3), st_ino=1032239, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=16, st_size= 1323, st_atime=2008/11/05-10:31:17, st_mtime=2007/08/09-19:54:26, st_ctime=2007/08/09-19:54:26}) = 0 13637 stat64("/etc/localtime", {st_dev=makedev(3, 3), st_ino=1032239, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=16, st_size= 1323, st_atime=2008/11/05-10:31:17, st_mtime=2007/08/09-19:54:26, st_ctime=2007/08/09-19:54:26}) = 0 13637 stat64("/etc/localtime", {st_dev=makedev(3, 3), st_ino=1032239, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=16, st_size= 1323, st_atime=2008/11/05-10:31:17, st_mtime=2007/08/09-19:54:26, st_ctime=2007/08/09-19:54:26}) = 0 13637 send(3, "<167>Nov 5 10:34:39 slapd[13628"..., 76, MSG_NOSIGNAL) = 76 looks like it connect to mysql but never queries it. any way I can capture something useful with gdb?

1 0

(ITS#5802) nssov_uid2dn using wrong LDAP filter
by ralf＠OpenLDAP.org 10 Nov '08

10 Nov '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.136.132) Submitted by: ralf The uid2dn function to resolve a username into a DN uses filters of the form "(&(objectclass=posixAccount)(uidNumber=<username>))" in it's query. The correct filter would be: "(&(objectclass=posixAccount)(uid=<username>))" Fix will appear in CVS soon.

1 0

(ITS#5801) "nssov-map" directive cause slapd to crash on startup
by ralf＠OpenLDAP.org 10 Nov '08

10 Nov '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.136.132) Submitted by: ralf Adding the line: nssov-map group uniquemember member To the nssov configuration in /etc/openldap/slapd.conf cause slapd to crash on startup. I'll commit a fix to HEAD shortly.

1 0

(ITS#5800) nssov overlay crashing on empty groups
by ralf＠OpenLDAP.org 10 Nov '08

10 Nov '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.136.132) Submitted by: ralf Calling "getent group" causes the nssov-overlay to crash, when there are "posixGroups" without members. A fix is coming.

1 0

(ITS#5799) smbk5pwd update to work with heimdal 1.2 API
by admin＠dmarkey.com 10 Nov '08

10 Nov '08

Full_Name: David Markey Version: 2.4 OS: Solaris/AIX/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.97.241.103) Update smbk5pwd to work with the heimdal 1.2 API. Work has been done on the mailing list but the patches have not been applied to the release.

1 0

Missing module PPolicy with openldap on CentOS5.0!
by Nguyen Quang Huy 10 Nov '08

10 Nov '08

Dear all! I'm setup openldap + CentOS 5.0 (I'm setup by YUM). I'm setup and configure test LDAP --> Ok, but I can't configure password policies for Openldap beacause openldap missing ppolicy module. I'm searching with google this error, but I can't append module ppolicy. Please help me!! Thanks.

3 2

Re: (ITS#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> IMO defaulting schemacheck off for replication is fine because >> replicated entries will have been checked on the master. > > What if two simulaneous, valid changes to the same entry on two masters > produce a schema error when combined? I haven't been tracking MMR - > does the entry end up with a schema error, or does MMR consider two > changes to the same entry a conflict and fail to replicate, or...? AFAIK, the last entryCSN should win. Something like: MM1 MM2 time 0 csn0 csn0 (same) time 1 csn0+1 -> - time 2 - <- csn0+2 time 3 csn0+1,csn0+2 csn0+2,csn0+1 (one wins, I assume the latest) At all times, each entry is sane. The one that wins is sane, the one that loses will be replaced by the one that wins. The reason for this ITS and other stuff that will come shortly is that I've been asked to audit MMR, by designing a suite of tests that check functionality and reliability of MMR under possibly reproducible conflict, concurrency and other critical conditions. I'm highlighting a series of issues. I won't post ITSes or other notices until I find out whether it's slapd's or my tests' fault. 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#5798) MMR/mirror mode circumvents schema check
by h.b.furuseth＠usit.uio.no 08 Nov '08

08 Nov '08

hyc(a)symas.com writes: > IMO defaulting schemacheck off for replication is fine because > replicated entries will have been checked on the master. What if two simulaneous, valid changes to the same entry on two masters produce a schema error when combined? I haven't been tracking MMR - does the entry end up with a schema error, or does MMR consider two changes to the same entry a conflict and fail to replicate, or...? -- Hallvard

1 0

Re: (ITS#5798) MMR/mirror mode circumvents schema check
by hyc＠symas.com 08 Nov '08

08 Nov '08

Howard Chu wrote: > All we have to do is change the code from setting the DB flag to using the > per-op o_no_schema_check flag. IMO defaulting schemacheck off for replication > is fine because replicated entries will have been checked on the master. Of course, it was already using the per-op flag too. Probably meant to remove the per-DB flag and forgot to some time ago. Fixed now in HEAD. -- -- 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#5798) MMR/mirror mode circumvents schema check
by hyc＠symas.com 08 Nov '08

08 Nov '08

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> When syncrepl is configured, schema checking is switched off. As a consequence, >> schema checking does not occur for all writes, including direct writes from >> clients when MMR/MM is in use. >> >> Internal writes performed by syncrepl should be marked as such, in order to >> disable schema checking only when appropriate. > > It all seems to boil down to the fact that syncrepl schemachecking is > off by default. So, not specifying any results in having multimasters > with schemachecking disabled, which is not desirable. I recommend > schema checking be on by default. All we have to do is change the code from setting the DB flag to using the per-op o_no_schema_check flag. IMO defaulting schemacheck off for replication is fine because replicated entries will have been checked on the master. -- -- 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#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 Nov '08

Howard Chu wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: HEAD/re24 >>> OS: irrelevant >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (82.63.140.131) >>> Submitted by: ando >>> >>> >>> When syncrepl is configured, schema checking is switched off. As a >>> consequence, >>> schema checking does not occur for all writes, including direct >>> writes from >>> clients when MMR/MM is in use. >>> >>> Internal writes performed by syncrepl should be marked as such, in >>> order to >>> disable schema checking only when appropriate. >> >> It all seems to boil down to the fact that syncrepl schemachecking is >> off by default. So, not specifying any results in having multimasters >> with schemachecking disabled, which is not desirable. I recommend >> schema checking be on by default. > > All we have to do is change the code from setting the DB flag to using > the per-op o_no_schema_check flag. IMO defaulting schemacheck off for > replication is fine because replicated entries will have been checked on > the master. Well, it used to be so, but now with MMR (and mirror mode) it's no longer so. Using the per-op is fine, as long as the caller consistently sets it. 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#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 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) (82.63.140.131) > Submitted by: ando > > > When syncrepl is configured, schema checking is switched off. As a consequence, > schema checking does not occur for all writes, including direct writes from > clients when MMR/MM is in use. > > Internal writes performed by syncrepl should be marked as such, in order to > disable schema checking only when appropriate. It all seems to boil down to the fact that syncrepl schemachecking is off by default. So, not specifying any results in having multimasters with schemachecking disabled, which is not desirable. I recommend schema checking be on by default. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5798) MMR/mirror mode circumvents schema check
by ando＠sys-net.it 08 Nov '08

08 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When syncrepl is configured, schema checking is switched off. As a consequence, schema checking does not occur for all writes, including direct writes from clients when MMR/MM is in use. Internal writes performed by syncrepl should be marked as such, in order to disable schema checking only when appropriate. p.

1 0

Re: (ITS#5797) build failed
by ando＠sys-net.it 08 Nov '08

08 Nov '08

cycwj(a)163.com wrote: > Full_Name: bluewind > Version: 2.4.12 > OS: ubunt server 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (219.133.134.8) > > > try to build on ubutnu server 8, use install manaul from www.openldap.org > > #./configure (ok) > #make depen (ok) > #make (ok) > > but,when execution > > #make test > > the system stop on "Running slapadd to build slapd database...", no any > response > > after about 1 hour Thanks for the detailed report. Did you read <http://www.openldap.org/faq/data/cache/56.html>, significantly <http://www.openldap.org/faq/data/cache/58.html>, <http://www.openldap.org/faq/data/cache/59.html> and <http://www.openldap.org/faq/data/cache/1122.html>? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5797) build failed
by cycwj＠163.com 06 Nov '08

06 Nov '08

Full_Name: bluewind Version: 2.4.12 OS: ubunt server 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (219.133.134.8) try to build on ubutnu server 8, use install manaul from www.openldap.org #./configure (ok) #make depen (ok) #make (ok) but,when execution #make test the system stop on "Running slapadd to build slapd database...", no any response after about 1 hour

1 0

Re: (ITS#5773) bi_entry_get_rw() and overlays issue
by hyc＠symas.com 06 Nov '08

06 Nov '08

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> I think bi_entry_get_rw() needs work. >> Or maybe phase it out in favor of some other call? >> >>> In fact, as also discussed in ITS#5628, callers either return the >>> entry or have no means to modify the arguments of the request. >> It has more troubles than that. See e.g. the notes about passing rw=1 >> (write) to it here: >> http://www.openldap.org/lists/openldap-devel/200803/msg00055.html >> And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which >> says to pass an rw=1 argument to bi_entry_release_rw(). > > Well, I see many places where an entry needs to be fetched. Typically, > it needs to be done read-only. In fact, the rw flag makes no sense. You can only fetch an entry ro; if you actually fetched it for write access and modified the entry, there's no API to commit the changed entry to stable storage. You would only be making a transient change to a cached copy (which could disappear as soon as you release the entry). So if we're going to change this API, the first thing to do is get rid of the rw flag. You must use be_modify if you want to change anything about an entry... > So the difference between > bi_entry_get_ro() and an internal search is that if we are fine with the > entry in-cache, we save lots of manipulation. However this might no > longer suffice when overlays muck with the entry (like slapo-rwm). > Moreover, when overlays are present, I see the need to: > 1) run it like it came from outside, going thru all the overlays That's what overlays currently do when they do the bd_info swap and then call be_entry_get_rw(). > 2) go straight to the underlying database That's done by calling bd_info->bi_entry_get_rw()... > 3) go thru overlays starting at some point (e.g. when called from inside > an overlay under the assumption the entry is fetched as that overlay > would see it, so with only any possible mucking from overlays layered > deeper than the caller). That's what overlay_entry_get_ov() does. Also note that passing a NULL overinst here accomplishes (2). > This probably needs to modify the way > callbacks are actually called, allowing some "after self" feature in > playing not just the overlay list, but also the response (and the cleanup). Then we need an "opcode" for this, so that response / cleanup handlers know why they're being invoked. -- -- 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

(ITS#5796) back-sql intermittently failing
by robb＠wtg.cw.com 06 Nov '08

06 Nov '08

Full_Name: Robert Brooks Version: 2 OS: 2.4.12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.49.19.14) Set up is a pair of centos 4 hosts, one acts as primary, the other is a syncrepl consumer and mysql slave. Apart from syncrepl config/myqsl slave all config and software versions are the same. Mysql queries on both hosts are to localhost via socket. After a period of operation (24-48 hours) the slave host drops the back-sql part of directory for some queries (same query will suceed some times). Using strace it can been seen that the ldap searches are not resulting in queries to mysql. Back-sql is a subordinate db and results from hdb backed part of directory are returned. Restarting slapd fixes the problem, but start-up reports the shutdown was unclean on hdb db. Operation of primary is reliable.

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 06 Nov '08

06 Nov '08

ali.pouya(a)free.fr wrote: > Howard Chu wrote : > >> I see. >> >> This has been fixed for back-bdb/hdb in HEAD. If the database was shut down >> cleanly before, there will be no scan on the next startup. > > Hi Howard, > Thanks for the corrections. > We tested the HEAD extracted on monday november 3. Unfortunately the problem > explained in point 2 persists (even after a clean shutdown). > Our directory contains 10 million entries. It can evolve to 40 million entries > next year. > The local sacanning speed is around 250 000 entries per minute. > So the scan of the recent objects on the standby mirror after startup can take > several minutes (unless if we distribute the write operations on both mirrors). I don't see this happening on my builds. Maybe you should post your configs and a sample of the data and modifications used to illustrate the problem. -- -- 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#5783) Possible DB corruption
by hyc＠symas.com 06 Nov '08

06 Nov '08

Maykel Moya wrote: > El jue, 06-11-2008 a las 07:30 -0800, Howard Chu escribió: > >> moya(a)latertulia.org wrote: >>> Full_Name: Maykel Moya >>> Version: 2.4.11 >>> OS: Debian Lenny >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (200.55.135.211) >>> >>> >>> It's second time that I have bitten by this: >>> >>> Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. >>> >>> After that I'm unable to bind against the DSA. The problem has arise in two >>> independent systems. >> This is now fixed in HEAD. > > Oh, thanks. Is there a way I can get the patch for applying it to my > system? See the diff here http://www.openldap.org/lists/openldap-commit/200811/msg00034.html -- -- 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#5794) Password exop unwilling to verify old password
by hyc＠symas.com 06 Nov '08

06 Nov '08

aja(a)nlgroup.ca wrote: > Full_Name: Arthur Anhalt > Version: 2.4.12 > OS: Ubuntu 8.04 > URL: > Submission from: (NULL) (205.200.169.138) > > > When parsing password change extended operations, > servers/slapd/passwd.c:slap_passwd_parse() calls ber_get_stringbv() with > LBER_BV_NOTERM set. The resulting bv_val doesn't end with a \0. > > In libraries/liblutil/passwd.c:chk_crypt will return an error is the old and > new > passwords do not end with a null terminator. I believe more of the chk_* > functions > return the same error. > > This is the same bug as ITS#5575, but affects the core system, not contributed > code. Fixed in HEAD, thanks. -- -- 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#5783) Possible DB corruption
by moya＠latertulia.org 06 Nov '08

06 Nov '08

El jue, 06-11-2008 a las 07:30 -0800, Howard Chu escribió: > moya(a)latertulia.org wrote: > > Full_Name: Maykel Moya > > Version: 2.4.11 > > OS: Debian Lenny > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (200.55.135.211) > > > > > > It's second time that I have bitten by this: > > > > Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. > > > > After that I'm unable to bind against the DSA. The problem has arise in two > > independent systems. > > This is now fixed in HEAD. Oh, thanks. Is there a way I can get the patch for applying it to my system? Regards, maykel

1 0

Re: (ITS#5783) Possible DB corruption
by hyc＠symas.com 06 Nov '08

06 Nov '08

moya(a)latertulia.org wrote: > Full_Name: Maykel Moya > Version: 2.4.11 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.55.135.211) > > > It's second time that I have bitten by this: > > Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. > > After that I'm unable to bind against the DSA. The problem has arise in two > independent systems. This is now fixed in HEAD. -- -- 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#5795) Modification of cn=config prevents to bind at next directory restart
by hyc＠symas.com 06 Nov '08

06 Nov '08

hyc(a)symas.com wrote: > 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 set a rootdn on cn=config which is a real entry >> (cn=admin,ou=somewhere,o=myorg,c=fr). >> I bind with this DN. >> I perform a change on cn=config (change the log level). >> At next slapd startup, I get: >> PROXIED attributeDescription "OU" inserted. >> PROXIED attributeDescription "O" inserted. >> PROXIED attributeDescription "C" inserted. >> and then when trying to bind, I get an invalid credentials error (49). >> The problem seems to come from modifiersname in cn=config entry, because if I >> delete this attribute and restarts slapd, all is fine. > > Ah, thanks for this. You're seeing the same as #5783, but you've provided much > more useful information here. > Now fixed in HEAD. -- -- 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#5795) Modification of cn=config prevents to bind at next directory restart
by hyc＠symas.com 06 Nov '08

06 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 set a rootdn on cn=config which is a real entry > (cn=admin,ou=somewhere,o=myorg,c=fr). > I bind with this DN. > I perform a change on cn=config (change the log level). > At next slapd startup, I get: > PROXIED attributeDescription "OU" inserted. > PROXIED attributeDescription "O" inserted. > PROXIED attributeDescription "C" inserted. > and then when trying to bind, I get an invalid credentials error (49). > The problem seems to come from modifiersname in cn=config entry, because if I > delete this attribute and restarts slapd, all is fine. Ah, thanks for this. You're seeing the same as #5783, but you've provided much more useful information here. -- -- 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

(ITS#5795) Modification of cn=config prevents to bind at next directory restart
by emmanuel.duru＠atosorigin.com 06 Nov '08

06 Nov '08

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 set a rootdn on cn=config which is a real entry (cn=admin,ou=somewhere,o=myorg,c=fr). I bind with this DN. I perform a change on cn=config (change the log level). At next slapd startup, I get: PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "O" inserted. PROXIED attributeDescription "C" inserted. and then when trying to bind, I get an invalid credentials error (49). The problem seems to come from modifiersname in cn=config entry, because if I delete this attribute and restarts slapd, all is fine.

1 0

(ITS#5794) Password exop unwilling to verify old password
by aja＠nlgroup.ca 05 Nov '08

05 Nov '08

Full_Name: Arthur Anhalt Version: 2.4.12 OS: Ubuntu 8.04 URL: Submission from: (NULL) (205.200.169.138) When parsing password change extended operations, servers/slapd/passwd.c:slap_passwd_parse() calls ber_get_stringbv() with LBER_BV_NOTERM set. The resulting bv_val doesn't end with a \0. In libraries/liblutil/passwd.c:chk_crypt will return an error is the old and new passwords do not end with a null terminator. I believe more of the chk_* functions return the same error. This is the same bug as ITS#5575, but affects the core system, not contributed code.

1 0

(ITS#5793) RFE for flexible logging at 256/stats level
by ghenry＠OpenLDAP.org 05 Nov '08

05 Nov '08

Full_Name: Gavin Henry Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.229.93.1) Submitted by: ghenry Hi all, Just a quick note to say it would be nice to be able to break out loglevel 256 i.e. Log just writes. The same as accesslog config. Thanks, Gavin.

1 0

(ITS#5792) structuralObjectClass modification w/ relax not conformant to draft-zeilenga-ldap-relax
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Current draft-zeilenga-ldap-relax requires the DSA to modify the structuralObjectClass attribute of an entry based on modifications of the structural objectClass of that entry. Slapd doesn't implement this; in order to obtain the desired effect, one needs to explicitly modify the structuralObjectClass attribute accordingly. This is explicitly forbidden by draft-zeilenga-ldap-relax. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs