openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5804) attribute value regex expantion
by ando＠sys-net.it 28 Nov '08

28 Nov '08

quanah(a)zimbra.com wrote: > --On November 28, 2008 9:07:49 PM +0000 quanah(a)zimbra.com wrote: > >> >> --On November 28, 2008 9:02:27 PM +0000 manu(a)netbsd.org wrote: >> >>> Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: >>> >>>> Turns out 'val' is nil and it doesn't seem like there's any check for >>>> that. Maybe naive fix: >>> I see Ando committed it. But there are many other locations in the file >>> where acl_string_expand is called with an unchecked val->bv_val. It >>> seems these also need to be fixed, but I miaght be missing a point. >> IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. > > Egh, in HEAD only, I mean, as this wasn't applied yet to RE24. :) I've reworked the use of string expansion (and lined up regex expansion in "by" dn). In order to fix ACIs, the dynacl API needs to be enhanced to support AclRegexMatches. 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#5804) attribute value regex expantion
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 28, 2008 9:07:49 PM +0000 quanah(a)zimbra.com wrote: > > > --On November 28, 2008 9:02:27 PM +0000 manu(a)netbsd.org wrote: > >> Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: >> >>> Turns out 'val' is nil and it doesn't seem like there's any check for >>> that. Maybe naive fix: >> >> I see Ando committed it. But there are many other locations in the file >> where acl_string_expand is called with an unchecked val->bv_val. It >> seems these also need to be fixed, but I miaght be missing a point. > > IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. Egh, in HEAD only, I mean, as this wasn't applied yet to RE24. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5804) attribute value regex expantion
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 28, 2008 9:02:27 PM +0000 manu(a)netbsd.org wrote: > Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: > >> Turns out 'val' is nil and it doesn't seem like there's any check for >> that. Maybe naive fix: > > I see Ando committed it. But there are many other locations in the file > where acl_string_expand is called with an unchecked val->bv_val. It > seems these also need to be fixed, but I miaght be missing a point. IIRC, this also broke ACI's in RE2.4, and that still needs fixing as well. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

28 Nov '08

Konstantinos Koukopoulos <kouk(a)noc.edunet.gr> wrote: > Turns out 'val' is nil and it doesn't seem like there's any check for > that. Maybe naive fix: I see Ando committed it. But there are many other locations in the file where acl_string_expand is called with an unchecked val->bv_val. It seems these also need to be fixed, but I miaght be missing a point. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 28, 2008 11:35:45 AM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > > --On November 28, 2008 7:24:27 PM +0000 quanah(a)zimbra.com wrote: > > >> As you can see, we lose a connection and then try to read from it (FD >> 40). This is where the log ends because the assert triggered. > > Printing the connection struct shows it is actually an issue with FD 26: The previous connection on FD 26 shows: Nov 29 00:27:02 new slapd[8930]: conn=335 fd=26 ACCEPT from IP=192.168.61.154:40988 (IP=192.168.58.179:389) Nov 29 00:27:02 new slapd[8930]: conn=335 op=0 STARTTLS Nov 29 00:27:02 new slapd[8930]: conn=335 op=0 RESULT oid= err=0 text= Nov 29 00:27:02 new slapd[8930]: conn=335 fd=26 TLS established tls_ssf=256 ssf=256 Nov 29 00:27:02 new slapd[8930]: conn=335 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Nov 29 00:27:02 new slapd[8930]: conn=335 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:27:02 new slapd[8930]: conn=335 op=1 RESULT tag=97 err=0 text= Nov 29 00:27:02 new slapd[8930]: conn=335 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Nov 29 00:27:02 new slapd[8930]: conn=335 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN [then nothing for a long time until]: Nov 29 00:29:41 new slapd[8930]: conn=335 fd=26 closed (connection lost) Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 RESULT tag=97 err=0 text= Nov 29 00:29:41 new slapd[8930]: conn=498 fd=26 ACCEPT from IP=192.168.58.231:45575 (IP=192.168.58.179:389) Nov 29 00:29:41 new slapd[8930]: connection_read(40): no connection! Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 RESULT tag=97 err=0 text= [slapd crashes] The consumer here in conn 335 is a refreshAndPersist consumer. Not entirely clear why it's connection gets closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

--On November 28, 2008 7:24:27 PM +0000 quanah(a)zimbra.com wrote: > As you can see, we lose a connection and then try to read from it (FD > 40). This is where the log ends because the assert triggered. Printing the connection struct shows it is actually an issue with FD 26: (gdb) print *c $1 = {c_struct_state = 2, c_conn_state = 2, c_conn_idx = 26, c_close_reason = 0x4be9fb "?", c_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x1000022ee, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_sb = 0xdcb1de0, c_starttime = 1227898781, c_activitytime = 1227898781, c_connid = 498, c_peer_domain = {bv_len = 7, bv_val = 0xe61c50 "unknown"}, c_peer_name = {bv_len = 23, bv_val = 0xc89d900 "IP=192.168.58.231:45575"}, c_listener = 0x88cf00, c_sasl_bind_in_progress = 0, 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 = 0xdeda80, c_authz_cookie = 0x0, c_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 30, bv_val = 0xdcb1d60 "uid=zimbra,cn=admins,cn=zimbra"}, sai_ndn = {bv_len = 30, bv_val = 0xdcb1cc0 "uid=zimbra,cn=admins,cn=zimbra"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 3, c_ops = {stqh_first = 0x0, stqh_last = 0x3670150}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x3670160}, c_write_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, c_write_cv = {__c_lock = {__status = 111669149696, __spinlock = 13}, __c_waiting = 0xd, __padding = "\r\000\000\000\000\000\000\000H\000g\003\000\000\000", __align = 0}, c_currentber = 0xdc6d410, c_writewaiter = 0, c_is_tls = 0, c_needs_tls_accept = 0, c_sasl_layers = 0, c_sasl_done = 0, c_sasl_authctx = 0x5d65000, c_sasl_sockctx = 0x0, c_sasl_extra = 0x5d64d98, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_cookie = 0, ps_count = 0}, c_n_ops_received = 1, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 1, c_n_get = 1, c_n_read = 1, c_n_write = 0, c_pb = 0x0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x43ea28 <slap_send_ldap_result>, c_send_search_entry = 0x43f723 <slap_send_search_entry>, c_send_search_reference = 0x441829 <slap_send_search_reference>, c_send_ldap_extended = 0x43f296 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x43f51a <slap_send_ldap_intermediate>} which is the connection currently logged as binding right before slapd crashes. --quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5834) enable modrDN rewriting
by ando＠sys-net.it 28 Nov '08

28 Nov '08

kouk(a)noc.uoa.gr wrote: > The 'modrDN' rewrite context, as mentioned in the slapo-rwm documentation, is > not implemented. Instead there is a undocumented context called 'renameDN' which > when undefined will use the default context. The submitted patch simply enables > the 'modrDN' context. The fix required a little bit more than that, in order to deal with errors and cleanup as appropriate. Fixed in HEAD, including slapo-rwm(5). Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

Full_Name: Quanah Gibson-Mount Version: 2.3.43 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Multiple clients have reported issues with their master servers dying. Examination of the logs showed frequent lost connections. Finally isolating a server today under GDB where it was occurring frequently I found the following in the backtrace: Thread 3 (Thread 1140881760 (LWP 8942)): #0 0x0000003fca02e21d in raise () from /lib64/tls/libc.so.6 #1 0x0000003fca02fa1e in abort () from /lib64/tls/libc.so.6 #2 0x0000003fca027ae1 in __assert_fail () from /lib64/tls/libc.so.6 #3 0x000000000042b55e in connection_close (c=0x3670030) at connection.c:877 #4 0x000000000042ca18 in connection_read (s=26, cri=0x44006e10) at connection.c:1458 #5 0x000000000042c1f8 in connection_read_thread (ctx=0x44006e90, argv=0x1a) at connection.c:1254 #6 0x0000002a956c7c77 in ldap_int_thread_pool_wrapper (xpool=0x8a1f00) at tpool.c:478 #7 0x0000003fca90610a in start_thread () from /lib64/tls/libpthread.so.0 #8 0x0000003fca0c68c3 in clone () from /lib64/tls/libc.so.6 #9 0x0000000000000000 in ?? () The connection.c code in question is: static void connection_close( Connection *c ) { ber_socket_t sd = AC_SOCKET_INVALID; assert( connections != NULL ); assert( c != NULL ); /* ITS#4667 we may have gotten here twice */ if ( c->c_conn_state == SLAP_C_INVALID ) return; assert( c->c_struct_state == SLAP_C_USED ); assert( c->c_conn_state == SLAP_C_CLOSING ); Example from stats level logging has: Nov 29 00:29:41 new slapd[8930]: conn=397 fd=40 closed (connection lost on write) Nov 29 00:29:41 new slapd[8930]: conn=335 fd=26 closed (connection lost) Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:29:41 new slapd[8930]: conn=496 op=0 RESULT tag=97 err=0 text= Nov 29 00:29:41 new slapd[8930]: conn=498 fd=26 ACCEPT from IP=192.168.58.231:45575 (IP=192.168.58.179:389) Nov 29 00:29:41 new slapd[8930]: connection_read(40): no connection! Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Nov 29 00:29:41 new slapd[8930]: conn=498 op=0 RESULT tag=97 err=0 text= As you can see, we lose a connection and then try to read from it (FD 40). This is where the log ends because the assert triggered. This is likely also problematic in OpenLDAP 2.4, as the code hasn't really changed much there. --Quanah

1 0

Re: (ITS#5834) enable modrDN rewriting
by ando＠sys-net.it 28 Nov '08

28 Nov '08

kouk(a)noc.uoa.gr wrote: > Full_Name: Kostantinos Koukopoulos > Version: HEAD > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/Kostantinos-Koukopoulos-081128.patch > Submission from: (NULL) (195.134.100.30) > > > The 'modrDN' rewrite context, as mentioned in the slapo-rwm documentation, is > not implemented. Instead there is a undocumented context called 'renameDN' which > when undefined will use the default context. The submitted patch simply enables > the 'modrDN' context. Thanks for noting this. I'd rather call "newRDN" the new rewrite context. Since the documentation is incorrect, I'd rather use "renameDN" for the old DN, and leave "newSuperiorDN" as is, since the documentation is consistent with the code. By default, "newRDN" should rather be empty, since the default rule rather applies to DNs that supposedly span the naming context. 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#5804) attribute value regex expantion
by ando＠sys-net.it 28 Nov '08

28 Nov '08

kouk(a)noc.edunet.gr wrote: > Turns out 'val' is nil and it doesn't seem like there's any check for > that. Maybe naive fix: The fix looks good. Applied to HEAD. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs