Re: (ITS#5804) attribute value regex expantion
by manu＠netbsd.org
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
14 years, 4 months
Re: (ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com
--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
14 years, 4 months
Re: (ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com
--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
14 years, 4 months
Re: (ITS#5834) enable modrDN rewriting
by ando＠sys-net.it
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
-----------------------------------
14 years, 4 months
(ITS#5835) master slapd dying on lost writes
by quanah＠zimbra.com
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
14 years, 4 months
Re: (ITS#5834) enable modrDN rewriting
by ando＠sys-net.it
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
-----------------------------------
14 years, 4 months
Re: (ITS#5804) attribute value regex expantion
by ando＠sys-net.it
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
-----------------------------------
14 years, 4 months
RE: (ITS#5832) Networking and Replication.
by quanah＠zimbra.com
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
14 years, 4 months
Re: (ITS#5804) attribute value regex expantion
by kouk＠noc.edunet.gr
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;
}
14 years, 4 months
