openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#8714)
by michael＠stroeder.com 05 Sep '17

05 Sep '17

hyc(a)symas.com wrote: > There's a weird indent at extended.c:50 or so, the if() > statement. > > Would be better to use op->o_tmpalloc instead of ber_memalloc > since you'r= e=20 immediately freeing the buffer again anyway. > > I can fix those here if you don't care. Yes, I'd highly appreciate if you simply adjust it to your coding style. One additional point: Currently the external program is not able to produce a custom extended operation response. Mainly it should always return CONTINUE or an error response. I wanted to make this limitation clear in the man-page but was unsure about the appropriate section. Ciao, Michael.

1 0

Re: (ITS#8714)
by hyc＠symas.com 05 Sep '17

05 Sep '17

Michael Str=C3=B6der wrote: > Howard Chu wrote: >> Your patch is missing extended.c >=20 > Aargh! Corrected herein: >=20 > https://www.stroeder.com/temp/0001-ITS-8714-Send-out-EXTENDED-operation= -message-from-back-sock_rev3.patch=20 There's a weird indent at extended.c:50 or so, the if() statement. Would be better to use op->o_tmpalloc instead of ber_memalloc since you'r= e=20 immediately freeing the buffer again anyway. I can fix those here if you don't care. --=20 -- 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#8714)
by michael＠stroeder.com 05 Sep '17

05 Sep '17

This is a cryptographically signed message in MIME format. --------------ms020207030808080005010306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > Your patch is missing extended.c Aargh! Corrected herein: https://www.stroeder.com/temp/0001-ITS-8714-Send-out-EXTENDED-operation-m= essage-from-back-sock_rev3.patch Ciao, Michael. --------------ms020207030808080005010306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTA1MTM1NjA1WjAvBgkq hkiG9w0BCQQxIgQg8GCP1w5NtTSxcpwIYyPNKa+KPNyCIiZ5C20j5QlpXN0wbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAQWsqReIlurKEhbkx577vMfgCmQaZVpXF0KGu367xj9DvBl9zN676ewWNz+H8r9bowUsX BvW5CocLPm0AyLAnsxgtIyyGX2OWci4da3dJs0Du1yjh1mjArfi/zmRVSFtKJEJgE7/dtWLF Vi/hVggifhJ/2vvvh4zQFGpi7pBeF+mv2YeUk9nrcOhVV6jr7rDyzRWXF2tvs+qv8BILtg+n vc4CnBTRL388vLzIreOAcORrUnJagh6IvRlydZyG4S2zXCBEOLwRzBkUADLqo5MmODiGuD8m X4Cnp0awozR+DYIrx6AhjzIpaCuWqoj6l3HG+6S2oNvY3ifwyH5Uj9cUHgAAAAAAAA== --------------ms020207030808080005010306--

1 0

Re: (ITS#8714)
by hyc＠symas.com 05 Sep '17

05 Sep '17

michael(a)stroeder.com wrote: > This is a multi-part message in MIME format. > --------------E329EF3D834E0A798BAC2EBC > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 7bit > > Find attached a new patch which base64-encoded the extended > operation request value before sending it to the socket. > > You can also download patch file here: Your patch is missing extended.c -- -- 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#8714)
by michael＠stroeder.com 05 Sep '17

05 Sep '17

This is a multi-part message in MIME format. --------------E329EF3D834E0A798BAC2EBC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Find attached a new patch which base64-encoded the extended operation request value before sending it to the socket. You can also download patch file here: https://www.stroeder.com/temp/0001-ITS-8714-Send-out-EXTENDED-operation-mes… Ciao, Michael. --------------E329EF3D834E0A798BAC2EBC Content-Type: text/x-patch; name="0001-ITS-8714-Send-out-EXTENDED-operation-message-from-back-sock_rev2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-ITS-8714-Send-out-EXTENDED-operation-message-from-back-"; filename*1="sock_rev2.patch" >From 7e584ffc4235f7e120b69acbd0b41cac9fe47ba3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michael=20Str=C3=B6der?= <michael(a)stroeder.com> Date: Tue, 5 Sep 2017 15:30:28 +0200 Subject: [PATCH] ITS#8714 Send out EXTENDED operation message from back-sock --- doc/man/man5/slapd-sock.5 | 19 ++++++++++++++++++- servers/slapd/back-sock/Makefile.in | 4 ++-- servers/slapd/back-sock/config.c | 12 ++++++++++-- servers/slapd/back-sock/init.c | 2 +- servers/slapd/back-sock/proto-sock.h | 2 ++ 5 files changed, 33 insertions(+), 6 deletions(-) diff --git a/doc/man/man5/slapd-sock.5 b/doc/man/man5/slapd-sock.5 index 1ac4f7fdd..b2fb21cc1 100644 --- a/doc/man/man5/slapd-sock.5 +++ b/doc/man/man5/slapd-sock.5 @@ -49,7 +49,7 @@ be sent and from which replies are received. When used as an overlay, these additional directives are defined: .TP -.B sockops [ bind | unbind | search | compare | modify | modrdn | add | delete ]* +.B sockops [ bind | unbind | search | compare | modify | modrdn | add | delete | extended ]* Specify which request types to send to the external program. The default is empty (no requests are sent). .TP @@ -115,6 +115,18 @@ dn: <DN> .PP .RS .nf +EXTENDED +msgid: <message id> +<repeat { "suffix:" <database suffix DN> }> +oid: <OID> +valuelen: <length of <value>> +value: <value> +<blank line> +.fi +.RE +.PP +.RS +.nf MODIFY msgid: <message id> <repeat { "suffix:" <database suffix DN> }> @@ -292,6 +304,11 @@ access to the pseudo_attribute of the searchBase; .B search (=s) access to the attributes and values used in the filter is not checked. +.LP +The +.B extended +operation does not require any access special rights. +The external program has to implement any sort of access control. .SH EXAMPLE There is an example script in the slapd/back\-sock/ directory diff --git a/servers/slapd/back-sock/Makefile.in b/servers/slapd/back-sock/Makefile.in index 3e527e545..efb916246 100644 --- a/servers/slapd/back-sock/Makefile.in +++ b/servers/slapd/back-sock/Makefile.in @@ -18,9 +18,9 @@ ## in OpenLDAP Software. SRCS = init.c config.c opensock.c search.c bind.c unbind.c add.c \ - delete.c modify.c modrdn.c compare.c result.c + delete.c modify.c modrdn.c compare.c result.c extended.c OBJS = init.lo config.lo opensock.lo search.lo bind.lo unbind.lo add.lo \ - delete.lo modify.lo modrdn.lo compare.lo result.lo + delete.lo modify.lo modrdn.lo compare.lo result.lo extended.lo LDAP_INCDIR= ../../../include LDAP_LIBDIR= ../../../libraries diff --git a/servers/slapd/back-sock/config.c b/servers/slapd/back-sock/config.c index dc3f1365c..2dcf68bf6 100644 --- a/servers/slapd/back-sock/config.c +++ b/servers/slapd/back-sock/config.c @@ -106,6 +106,7 @@ static ConfigOCs osocs[] = { #define SOCK_OP_MODRDN 0x020 #define SOCK_OP_ADD 0x040 #define SOCK_OP_DELETE 0x080 +#define SOCK_OP_EXTENDED 0x100 #define SOCK_REP_RESULT 0x001 #define SOCK_REP_SEARCH 0x002 @@ -127,6 +128,7 @@ static slap_verbmasks ov_ops[] = { { BER_BVC("modrdn"), SOCK_OP_MODRDN }, { BER_BVC("add"), SOCK_OP_ADD }, { BER_BVC("delete"), SOCK_OP_DELETE }, + { BER_BVC("extended"), SOCK_OP_EXTENDED }, { BER_BVNULL, 0 } }; @@ -249,7 +251,9 @@ static BI_op_bind *sockfuncs[] = { sock_back_modify, sock_back_modrdn, sock_back_add, - sock_back_delete + sock_back_delete, + 0, /* abandon not supported */ + sock_back_extended }; static const int sockopflags[] = { @@ -260,7 +264,9 @@ static const int sockopflags[] = { SOCK_OP_MODIFY, SOCK_OP_MODRDN, SOCK_OP_ADD, - SOCK_OP_DELETE + SOCK_OP_DELETE, + 0, /* abandon not supported */ + SOCK_OP_EXTENDED }; static int sock_over_op( @@ -283,6 +289,7 @@ static int sock_over_op( case LDAP_REQ_MODRDN: which = op_modrdn; break; case LDAP_REQ_ADD: which = op_add; break; case LDAP_REQ_DELETE: which = op_delete; break; + case LDAP_REQ_EXTENDED: which = op_extended; break; default: return SLAP_CB_CONTINUE; } @@ -365,6 +372,7 @@ sock_over_setup() sockover.on_bi.bi_op_modrdn = sock_over_op; sockover.on_bi.bi_op_add = sock_over_op; sockover.on_bi.bi_op_delete = sock_over_op; + sockover.on_bi.bi_extended = sock_over_op; sockover.on_response = sock_over_response; sockover.on_bi.bi_cf_ocs = osocs; diff --git a/servers/slapd/back-sock/init.c b/servers/slapd/back-sock/init.c index dcfe61a44..92e68782f 100644 --- a/servers/slapd/back-sock/init.c +++ b/servers/slapd/back-sock/init.c @@ -53,7 +53,7 @@ sock_back_initialize( bi->bi_op_delete = sock_back_delete; bi->bi_op_abandon = 0; - bi->bi_extended = 0; + bi->bi_extended = sock_back_extended; bi->bi_chk_referrals = 0; diff --git a/servers/slapd/back-sock/proto-sock.h b/servers/slapd/back-sock/proto-sock.h index fa02ab896..8b3b5f3ef 100644 --- a/servers/slapd/back-sock/proto-sock.h +++ b/servers/slapd/back-sock/proto-sock.h @@ -40,6 +40,8 @@ extern BI_op_modrdn sock_back_modrdn; extern BI_op_add sock_back_add; extern BI_op_delete sock_back_delete; +extern BI_op_extended sock_back_extended; + extern int sock_back_init_cf( BackendInfo *bi ); LDAP_END_DECL -- 2.14.1 --------------E329EF3D834E0A798BAC2EBC--

1 0

Re: (ITS#8723) slaptest reports success status in stderr
by hyc＠symas.com 05 Sep '17

05 Sep '17

arun(a)gluu.org wrote: > Full_Name: Arunmozhi > Version: 2.4 > OS: Ubuntu 14.04.5 x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.52.54.225) > > > slaptest when run with -f and -F arguments for slapd.conf to slapd.d conversion > returns all the messages only in stderr instead of returning success messages in > stdout. > > I am developing a tool which sends commands over SSH and catches the replies > using the Python Library Paramiko. It clearly captures stdin, stdout and stderr > when a command is run and returns to the user > (http://docs.paramiko.org/en/2.2/api/client.html#paramiko.client.SSHClient.e…) > > I noticed that the message "config file testing succeeded" is returned back in > the channel stderr and not stdout. > > Kindly take a look. It might be a one line fix. :) This is not a bug. slaptest doesn't produce any actual output, only diagnostic messages and an exit code. -- -- 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#8723) slaptest reports success status in stderr
by arun＠gluu.org 05 Sep '17

05 Sep '17

Full_Name: Arunmozhi Version: 2.4 OS: Ubuntu 14.04.5 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (103.52.54.225) slaptest when run with -f and -F arguments for slapd.conf to slapd.d conversion returns all the messages only in stderr instead of returning success messages in stdout. I am developing a tool which sends commands over SSH and catches the replies using the Python Library Paramiko. It clearly captures stdin, stdout and stderr when a command is run and returns to the user (http://docs.paramiko.org/en/2.2/api/client.html#paramiko.client.SSHClient.e…) I noticed that the message "config file testing succeeded" is returned back in the channel stderr and not stdout. Kindly take a look. It might be a one line fix. :) Thanks and Regards, Arunmozhi

1 0

Re: (ITS#8722) MDB_LAST_DUP/FIRST_DUP return item beyond last item
by h.b.furuseth＠usit.uio.no 05 Sep '17

05 Sep '17

On 05/09/17 08:46, h.b.furuseth(a)usit.uio.no wrote: > Happens with the test program without arguments. When run with > arguments so it uses a sub-page, it returns some other garbage. > Er, happens with the test program, period. With arguments it runs some other garbage than the program's "designed" garbage. Commit 8498c6cba2d78de420e626245a49db4705e5a6f6 "ITS#7913 mdb_cursor_get(*_DUP) cleanup" changed how the test program breaks: Before that, it said EINVAL when run without args (no sub-page).

1 0

(ITS#8722) MDB_LAST_DUP/FIRST_DUP return item beyond last item
by h.b.furuseth＠usit.uio.no 05 Sep '17

05 Sep '17

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.21, mdb.master, master2 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-170905.c Submission from: (NULL) (81.191.45.31) Submitted by: hallvard mdb_cursor_get(MDB_LAST_DUP/MDB_FIRST_DUP) can return a deleted item when mc_ki[] == NUMKEYS(), i.e. an "ack!" cursor in mdb_cursor_chk(). Happens with the test program without arguments. When run with arguments so it uses a sub-page, it returns some other garbage. $ ./a.out mc {flags 0x4b, ki-numkeys 0}; mx {flags 0x4, ki 0} cursor_get() = Successful return: 0 node: dsize 0x68686c6c, flags 0x6161, ksize 0x7a7a key "kkkkkkkkk...", data "<garbage>". Segmentation fault (core dumped) It should return MDB_NOTFOUND or last key:data item, not sure which. It should return the same when run with and without an argument.

1 0

(ITS#8721) Quarantine in meta backend
by michele.lugli＠unife.it 04 Sep '17

04 Sep '17

Full_Name: Michele Lugli Version: 2.4.45 OS: Linux Ubuntu server 16.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.167.209.10) Quarantine function in back-meta will permanently disable a target if a query is received while the quarantine has been imposed. Same problem reported in ITS#5592 and marked as "solved": still exists under some circustances. To reproduce: use config below, assume the first target works correctly and the second is unavailable. Send a query and the quarantine will be set. Sending more queries, with searchbase "dc=example,dc=com" and within 20 seconds, the quarantine will never lift. Tested on latest release available (commit bb62d9cb732c894023c5c9f5893acf40add7376c - Aug 31 16:53:45 2017). ---- slapd.conf ---- database meta suffix dc=example,dc=com quarantine 20,+ uri ldap://itworks.example.com/dc=subtree1,dc=example,dc=com uri ldap://afakeaddress/dc=subtree2,dc=example,dc=com ---- slapd logs ---- 59ad1507 conn=1000 op=1 meta_back_quarantine[1]: enter. 59ad1519 conn=1001 op=1: meta_back_getconn[1] quarantined 59ad1527 conn=1002 op=1: meta_back_getconn[1] quarantined 59ad1539 conn=1003 op=1: meta_back_getconn[1] quarantined 59ad154b conn=1004 op=1: meta_back_getconn[1] quarantined ....

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