- openldap-bugs - openldap.org

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 16 Nov '08

16 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 16 Nov '08

16 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 16 Nov '08

16 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 16 Nov '08

16 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 16 Nov '08

16 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 15 Nov '08

15 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 12 Nov '08

12 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs