openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

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

RE: (ITS#5832) Networking and Replication.
by quanah＠zimbra.com 28 Nov '08

28 Nov '08

The emails you sent directly to me were deleted. Send any comments CC'd or directly to the ITS system if you want them included. In either case, at least up to 2.4.12, BDB 4.7.25 has been fine for me (and others). --Quanah --On November 27, 2008 2:08:06 PM +0000 Nils.Hammar(a)cybercomgroup.com wrote: > ------=_NextPart_000_0029_01C950A1.DC1D8A50 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Further investigation into this issue seems to indicate that the problem > is more related to the Berkeley DB 4.7.25 database than it is related to > OpenLDAP itself. > > Sorry for causing trouble on this issue, I'll stick to 4.6 for the moment. > > > ------=_NextPart_000_0029_01C950A1.DC1D8A50 > Content-Type: application/x-pkcs7-signature; name="smime.p7s" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="smime.p7s" > > MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL+jCCA > j0w > ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXM > BUG > A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ > 2Vy > dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfM > Qsw > CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgU > HVi > bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADg > Y0A > MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWh > BiH > mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY > 1zF > 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DM > w5d > 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiX > bix > 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAm > PPR > cZQwggTMMIIENaADAgECAhAcrp1rmvTmLyKKo9p0YWweMA0GCSqGSIb3DQEBBQUAMF8xCzAJB > gNV > BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsa > WMg > UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwM > jcy > MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVB > AsT > FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwc > zov > L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZ > GF0 > ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBI > C0g > RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvf > HIV > y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEe > ksF > ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRH > QgV > N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7 > RXp > 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCb > OKv > H3n/27S1AgMBAAGjggGEMIIBgDASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLY > IZI > AYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALB > gNV > HQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQc > ml2 > YXRlTGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVH > R8E > KjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDCBgQYDVR0jBHowe > KFj > pGEwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5Db > GFz > cyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5ghEAzbp/VvDf5LxU/ > iKs > s3KqVTANBgkqhkiG9w0BAQUFAAOBgQCxL9mW4ZKi7oFg5cgqIPvhZyzWAJhTowIb6ZBL+BhEn > w9G > 9/qg/tMdGKPSvxzs1hmfSk1D+Mq7vhOASQXdIXMzV8JCWr76AJOy5gQxkU5dPPBzBTdj67+DW > Zj9 > Zt7phjKakik8Oq5U2qYSUbGPyMrTR3jm26Uehwbj0RTAwiH2ujCCBOUwggPNoAMCAQICEE2vq > tiu > yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZ > XJp > U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyV > GVy > bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVB > AsT > FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpd > mlk > dWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wODEwMTQwMDAwMDBaFw0wOTEwMTcyMzU5NTlaM > IIB > HDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ld > Hdv > cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBie > SBS > ZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA > 1UE > CxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEUMBIGA1UEA > xQL > TmlscyBIYW1tYXIxLDAqBgkqhkiG9w0BCQEWHW5pbHMuaGFtbWFyQGN5YmVyY29tZ3JvdXAuY > 29t > MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK9OCvNd7SoeHTv9CAtBkk2O4JDj37AtwYV > zyz > IiVvoqHZ9LEF8+WT4w+dUuFgsQfx1+bFd63U4SDuwzRj5KvIVbc+7FR1igcIdLZUU3Sxn4Ubd > PZT > tcYeyWt5Y8IuJK/k81uAeAo4nPvzwbMrymoIN4mBsB/RuH8fmr7o+00W/QIDAQABo4HiMIHfM > AkG > A1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwc > zov > L3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDB > AYI > KwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6L > y9J > bmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqh > kiG > 9w0BAQUFAAOCAQEAl5Y1KD8GgWQMmy6bFHps9DJqAG4TLPaGkz8IMg6Y9MbZeruhEZIYz5pZB > JCs > jjaejgiGIimQkirfVxg9aYl/hBPXDRmsyeruPg6Vx4GyQlS06ww/52ZYIawelQyyjk5tQQyQe > sJ4 > bnfNiTdAXTlujPnCN3POKXIIyjFEkD8MESudFm6Pv4lfFDV4eHAC8qd/AbPnV2WRG+SOL9YDO > oYd > N/rxL/X18/zcb8vFdzDuci3StC43LjOIoVAH7JUTFs8LHXi9gJcMyUiYGgDJ8m4eq3P/a4smz > KVM > ScHKUwTfX1W8Zs9onmsWDvTzjULkgojba/zs6oBvkdw8yCvYQM4DADGCBHMwggRvAgEBMIHyM > IHd > MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTa > Wdu > IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52Z > XJp > c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1B > gNV > BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vq > tiu > yqYVrOEv8MvOnVMwCQYFKw4DAhoFAKCCAtYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcB > gkq > hkiG9w0BCQUxDxcNMDgxMTI3MTQwNzI2WjAjBgkqhkiG9w0BCQQxFgQUrD6KW0bWJzupmxglk > rOq > mpCpvY4wZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIK > oZI > hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwg > gED > BgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgS > W5j > LjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2Ygd > XNl > IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvb > mEg > Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1Y > nNj > cmliZXIgQ0EgLSBHMgIQTa+q2K7KphWs4S/wy86dUzCCAQUGCyqGSIb3DQEJEAILMYH1oIHyM > IHd > MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTa > Wdu > IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52Z > XJp > c2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1B > gNV > BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEE2vq > tiu > yqYVrOEv8MvOnVMwDQYJKoZIhvcNAQEBBQAEgYCpBG16o6yJunOIxpD8tXIeMLpr785llp0rS > Fzi > Bl29rw1EWwsVlU5aRyHlKzZUOwdS/WhPLlAb10aQUcCHv+2QDcWjLId+zOjQiubYHNCyh7inW > H+u 0dqDDTAMyVbBd6yDUWWIN7MQ+++vyCBJ0WCSDE2DsYhhg19h9v2C4s49KAAAAAAAAA== > > ------=_NextPart_000_0029_01C950A1.DC1D8A50-- > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5834) enable modrDN rewriting
by kouk＠noc.uoa.gr 28 Nov '08

28 Nov '08

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.

1 0

Re: (ITS#5804) attribute value regex expantion
by kouk＠noc.edunet.gr 28 Nov '08

28 Nov '08

I got segfault with the latest cvs and I think it's related to this ITS. It happened when slapd was evaluating the acl pattern. by dn.exact,expand="uid=$1,ou=people,dc=domain,dc=gr" write The relevant info from the debugger was: <= check a_dn_pat: uid=1,ou=people,dc=domain,dc=gr t@3 (l@3) signal SEGV (no mapping at the fault address) in acl_mask_dn at line 914 in file "acl.c" 914 val->bv_val, tmp_matchesp ) ) /SCRATCH/NG/ldap.devel-2.4/UOAldap.sources/openldap-cvs-20081128/servers/slapd> /SCRATCH/NG/ldap.devel-2.4/UOAldap.sources/openldap-cvs-20081128/servers/slapd> /SCRATCH/NG/ldap.devel-2.4/UOAldap.sources/openldap-cvs-20081128/servers/slapd>where current thread: t@3 =>[1] acl_mask_dn(op = 0x3e4440, e = 0x3b217c, val = (nil), a = 0x36c118, matches = 0xfcffde64, bdn = 0x36cfd0, opndn = 0x3e44dc), line 914 in "acl.c" [2] slap_acl_mask(a = 0x36c118, mask = 0xfcfff138, op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), matches = 0xfcffde64, count = 5, state = 0xfcffde48, access = ACL_WADD), line 1184 in "acl.c" [3] slap_access_allowed(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = 0xfcffde48, maskp = 0xfcfff3e0), line 297 in "acl.c" [4] fe_access_allowed(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = (nil), maskp = 0xfcfff3e0), line 359 in "acl.c" [5] over_access_allowed(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = (nil), maskp = 0xfcfff3e0), line 312 in "backover.c" [6] access_allowed_mask(op = 0x3e4440, e = 0x3b217c, desc = 0x322698, val = (nil), access = ACL_WADD, state = (nil), maskp = (nil)), line 462 in "acl.c" [7] bdb_add(op = 0x3e4440, rs = 0xfcfffcb0), line 284 in "add.c" [8] fe_op_add(op = 0x3e4440, rs = 0xfcfffcb0), line 334 in "add.c" [9] overlay_op_walk(op = 0x3e4440, rs = 0xfcfffcb0, which = op_add, oi = 0x3614f8, on = (nil)), line 670 in "backover.c" [10] over_op_func(op = 0x3e4440, rs = 0xfcfffcb0, which = op_add), line 722 in "backover.c" [11] over_op_add(op = 0x3e4440, rs = 0xfcfffcb0), line 768 in "backover.c" [12] do_add(op = 0x3e4440, rs = 0xfcfffcb0), line 194 in "add.c" [13] connection_operation(ctx = 0xfcfffe0c, arg_v = 0x3e4440), line 1090 in "connection.c" [14] connection_read_thread(ctx = 0xfcfffe0c, argv = 0xd), line 1216 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x326dd0), line 663 in "tpool.c" Turns out 'val' is nil and it doesn't seem like there's any check for that. Maybe naive fix: =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/acl.c,v retrieving revision 1.347 diff -u -r1.347 acl.c --- servers/slapd/acl.c 16 Nov 2008 02:22:27 -0000 1.347 +++ servers/slapd/acl.c 28 Nov 2008 14:28:34 -0000 @@ -911,7 +911,7 @@ if ( acl_string_expand( &bv, &bdn->a_pat, e->e_nname.bv_val, - val->bv_val, tmp_matchesp ) ) + (val?val->bv_val:NULL), tmp_matchesp ) ) { return 1; }

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 November 2008