openldap-bugs September 2017

openldap-bugs@openldap.org

35 participants
128 discussions

(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 04 Sep '17

04 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

Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant connections occur.
by yos-nishino＠ys.jp.nec.com 03 Sep '17

03 Sep '17

Dear Howard-san, >That comment only applies when using LDAP_MEMORY_DEBUG and is irrelevant. I saw memory.c again.=20 As you told, I confirmed the comment was available only when LDAP_MEMORY_DE= BUG was used(from line 27 to line 119). I am sorry to bother you, and I am grateful for your help. I am going to use "case2" patch, which I expect slapd_crypt() becomes much = faster. Best Reagrds, ************************************************ Yoshinori Nishino NEC Solution Innovators, Ltd. 1-18-7 Shinkiba, Koto-ku, Tokyo, 136-8627 Japan E-MAIL: yos-nishino(a)ys.jp.nec.com ************************************************

1 0

Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant connections occur.
by hyc＠symas.com 03 Sep '17

03 Sep '17

Yoshinori Nishino wrote: > Dear Howard-san, > >> There is no issue with thread-safety for ber_strdup. What exact line of memory.c are you talking about? > > I think ber_strdup(), which uses ber_memalloc_x(), is non thread-safe because of the following comment at around line 69 of memory.c: > > /* Note sequence and ber_int_meminuse are counters, but are not > * thread safe. If you want to use these values for multithreaded applications, > * you must put mutexes around them, otherwise they will have incorrect values. > * When debugging, if you sort the debug output, the sequence number will > * put allocations/frees together. It is then a simple matter to write a script > * to find any allocations that don't have a buffer free function. > */ That comment only applies when using LDAP_MEMORY_DEBUG and is irrelevant. -- -- 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#8719) slapd_crypt() become slow when many ldap cliant connections occur.
by yos-nishino＠ys.jp.nec.com 03 Sep '17

03 Sep '17

Dear Howard-san, >There is no issue with thread-safety for ber_strdup. What exact line of me= mory.c are you talking about? I think ber_strdup(), which uses ber_memalloc_x(), is non thread-safe becau= se of the following comment at around line 69 of memory.c: /* Note sequence and ber_int_meminuse are counters, but are not * thread safe. If you want to use these values for multithreaded applicat= ions, * you must put mutexes around them, otherwise they will have incorrect val= ues. * When debugging, if you sort the debug output, the sequence number will=20 * put allocations/frees together. It is then a simple matter to write a s= cript * to find any allocations that don't have a buffer free function. */ Best Regards, ************************************************ Yoshinori Nishino NEC Solution Innovators, Ltd. 1-18-7 Shinkiba, Koto-ku, Tokyo, 136-8627 Japan E-MAIL: yos-nishino(a)ys.jp.nec.com ************************************************

1 0

Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant connections occur.
by hyc＠symas.com 03 Sep '17

03 Sep '17

Yoshinori Nishino wrote: > I decide to use passwd_mutex only for ber_strdup(), which seems to be non thread-safe according to ./libraries/liblber/memory.c. There is no issue with thread-safety for ber_strdup. What exact line of memory.c are you talking about? -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2017