openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

(ITS#8110) ldap_sasl_bind_s does not honor LDAP_OPT_NETWORK_TIMEOUT for TLS connections
by ahochhaus＠samegoal.com 21 Apr '15

21 Apr '15

Full_Name: Andy Version: 2.4.30 OS: Debian Linux (Jessie) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.188.115.159) Hello, When connecting over TLS to an LDAP server with high packet loss, my calls to ldap_sasl_bind_s() block forever some of the time despite have set a 10s limit on all of LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMEOUT and LDAP_OPT_TIMELIMIT. I see the following stack trace on the deadlocked process. @ 0x7f2ff0c0f8d0 (unknown) @ 0x7f2ff0c0eac0 __libc_read @ 0x5cdc68 sb_debug_read @ 0x5c26f5 tlso_bio_read @ 0x451b64 BIO_read @ 0x49bf86 ssl3_read_n @ 0x49d52b ssl3_get_record @ 0x49caea ssl3_read_bytes @ 0x496f61 ssl3_get_message @ 0x496944 ssl3_get_finished @ 0x5e4aab ssl3_connect @ 0x5e164b ssl23_connect @ 0x5c1b3c tlso_session_connect @ 0x5b6773 ldap_int_tls_start @ 0x5b3a77 ldap_int_open_connection @ 0x5a730e ldap_new_connection @ 0x5b3365 ldap_open_defconn @ 0x5a68e3 ldap_send_initial_request @ 0x5a4c1e ldap_sasl_bind @ 0x5a4d99 ldap_sasl_bind_s Inspecting the source, I see that SSL_connect() is called from tlso_session_connect(). Does openldap attempt to pass timeout information to openssl? Sorry for the vague bug report. The issue is non-deterministic so it is hard to provide too much information. Please let me know what I can do to be more helpful. I was able to find an old posting (from 2006) reporting a similar issue. I'm uncertain if the root cause is the same or not though. http://www.openldap.org/lists/openldap-software/200601/msg00440.html Thanks, -Andy

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 20 Apr '15

20 Apr '15

Good day Michael. I built the branch OPENLDAP_REL_ENG_2_4 revision d281bd3, unfortunately connection 0 still shows up twice. The source code of my test case is here: https://github.com/HouzuoGuo/ldap-conn0 Would you mind to try it out in your test environment? Thanks. Regards, Howard On 10/04/15 15:44, Michael Ströder wrote: > hguo(a)suse.com wrote: >> Is your build identical to the 2.4.40 on OBS in terms of patches/source >> code revision? > > No. It's RE24 with all changes to be released as 2.4.41. > >> What distribution did you use for testing? > > openSUSE Tumbleweed x86_64. > > Ciao, Michael. > .

1 0

Re: (ITS#8095) Patch
by rouzier＠gmail.com 19 Apr '15

19 Apr '15

--047d7bfcf1deec63470514165cd2 Content-Type: text/plain; charset=UTF-8 My Testing does show it is not worth it for the data size in the db. Also there is a race condition using sendfile on linux that could happen. It is avoidable but it would require changes to the protocol to avoid it which I am not willing to do. So dismiss my patch with extreme prejudice On Wed, Apr 15, 2015 at 10:37 PM, Howard Chu <hyc(a)symas.com> wrote: > rouzier(a)gmail.com wrote: > >> Full_Name: James Rouzier >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch >> Submission from: (NULL) (192.222.129.11) >> >> >> I am working on a proof of concept of a simple key value store service >> using >> lmdb as the back end. >> I am using sendfile to avoid an extra copy. >> I accomplished this by creating function to extract get the mmap ptr from >> the >> env so I can calculate the offset of data. >> > > I'm quite reluctant to return the mmap pointer. In a WRITEMAP environment > that invites all manner of undetectable/unpreventable corruptions. > > Have you actually measured the performance difference between using > sendfile() here and plain write() or send()? The kernel doesn't physically > copy the written data from user space to kernel space, it just maps in a > particular page. Since LMDB data is already mmap'd, the kernel has very > little work to do since the relevant pages are already present in the > kernel's page tables. > > Ultimately sending data over TCP involves byte-by-byte iteration anyway, > since TCP checksums must be computed on all outgoing data. Doesn't seem to > me like sendfile can be a very significant optimization here. > >> >> I figured that function might be useful to the bigger community. >> >> If it does not fit in the bigger vision of lmdb it is fine not to include >> it. >> >> >> I, James Rouzier, hereby place the following modifications to OpenLDAP >> Software >> (and only these modifications) into the public domain. Hence, these >> modifications may be freely used and/or redistributed for any purpose >> with or >> without attribution and/or other notice. >> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --047d7bfcf1deec63470514165cd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">My Testing doe= s show it is not worth it for the data size in the db.<br><br><div>Also the= re is a race condition using sendfile on linux that could happen.<br>It is = avoidable but it would require changes to=C2=A0the protocol to avoid it whi= ch I am not willing to do.<br><br>So dismiss my patch with extreme prejudic= e<br><br><br></div></div><div><div><div class=3D"gmail_extra"><br><div clas= s=3D"gmail_quote">On Wed, Apr 15, 2015 at 10:37 PM, Howard Chu <span dir=3D= "ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com<= /a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:r= ouzier(a)gmail.com" target=3D"_blank">rouzier(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: James Rouzier<br> Version:<br> OS:<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch"= target=3D"_blank">ftp://ftp.openldap.org/incoming/james-rouzier-150331.pat= ch</a><br> Submission from: (NULL) (192.222.129.11)<br> <br> <br> I am working on a proof of concept of a simple key value store service usin= g<br> lmdb as the back end.<br> I am using sendfile to avoid an extra copy.<br> I accomplished this by creating function to extract get the mmap ptr from t= he<br> env so I can calculate the offset of data.<br> </blockquote> <br> I'm quite reluctant to return the mmap pointer. In a WRITEMAP environme= nt that invites all manner of undetectable/unpreventable corruptions.<br> <br> Have you actually measured the performance difference between using sendfil= e() here and plain write() or send()? The kernel doesn't physically cop= y the written data from user space to kernel space, it just maps in a parti= cular page. Since LMDB data is already mmap'd, the kernel has very litt= le work to do since the relevant pages are already present in the kernel&#3= 9;s page tables.<br> <br> Ultimately sending data over TCP involves byte-by-byte iteration anyway, si= nce TCP checksums must be computed on all outgoing data. Doesn't seem t= o me like sendfile can be a very significant optimization here.<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> I figured that function might be useful to the bigger community.<br> <br> If it does not fit in the bigger vision of lmdb it is fine not to include i= t.<br> <br> <br> I, James Rouzier, hereby place the following modifications to OpenLDAP Soft= ware<br> (and only these modifications) into the public domain. Hence, these<br> modifications may be freely used and/or redistributed for any purpose with = or<br> without attribution and/or other notice.<br> <br> <br> <br><span><font color=3D"#888888"> </font></span></blockquote><span><font color=3D"#888888"> <br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </font></span></blockquote></div><br></div> </div></div></div><br></div> --047d7bfcf1deec63470514165cd2--

1 0

(ITS#8109) SEGFAULT mdb_cursor_del mdb_cursor_get(MDB_PREV)
by rouzier＠gmail.com 19 Apr '15

19 Apr '15

Full_Name: James Rouzier Version: LMDB mdb.master OS: linux URL: https://gist.github.com/rouzier/2d268a2f24e82e00f498 Submission from: (NULL) (70.81.32.80) When iterating with a cursor using MDB_PREV and deleting entries using mdb_cursor_del. It will crash when calling mdb_cursor_get after the last entry was deleted. I am using the latest version of LMDB in git.

1 0

(ITS#8108) possible bug in slapcat(8)
by igor.shmukler＠gmail.com 19 Apr '15

19 Apr '15

Full_Name: Igor Shmukler Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.146.103.114) I make a use of olcHidden. When set to true, olcHidden breaks slapcat. $ sudo slapcat -n 0 5530b282 olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix 5530b282 config error processing olcDatabase={2}hdb,cn=config: <olcRootPW> can only be set when rootdn is under suffix slapcat: bad configuration file!

1 0

Re: (ITS#8107) olcMemberOfDangling: error doesn't prevent adding nonexistent member to group
by ryan＠nardis.ca 18 Apr '15

18 Apr '15

Adding a new group containing a nonexistent member, or or a nonexistent member to an existing group, triggers the following AddressSanitizer splat. No error when adding a valid member, or with memberof disabled. (Line numbers from git master) 5532dc8c connection_get(11): got connid=1000 5532dc8c connection_read(11): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 66 contents: 5532dc8c op tag 0x66, time 1429396620 ber_get_next 5532dc8c conn=1000 op=2 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: 5532dc8c >>> dnPrettyNormal: <cn=testgroup,dc=example,dc=com> 5532dc8c <<< dnPrettyNormal: <cn=testgroup,dc=example,dc=com>, <cn=testgroup,dc=example,dc=com> 5532dc8c >>> dnPretty: <cn=dummy> 5532dc8c <<< dnPretty: <cn=dummy> 5532dc8c >>> dnNormalize: <cn=dummy> 5532dc8c <<< dnNormalize: <cn=dummy> 5532dc8c => mdb_search 5532dc8c mdb_dn2entry("cn=testgroup,dc=example,dc=com") 5532dc8c => mdb_dn2id("cn=testgroup,dc=example,dc=com") 5532dc8c <= mdb_dn2id: got id=0x3 5532dc8c => mdb_entry_decode: 5532dc8c <= mdb_entry_decode 5532dc8c send_ldap_result: conn=1000 op=2 p=3 5532dc8c mdb_dn2entry("cn=dummy") 5532dc8c => mdb_dn2id("cn=dummy") ================================================================= ==1998==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000024967 at pc 0x000000ebdb1f bp 0x7f91f2773650 sp 0x7f91f2773648 READ of size 1 at 0x602000024967 thread T2 #0 0xebdb1e in lutil_strncopy /home/ryan/pkg/openldap/openldap/libraries/liblutil/utils.c:317:2 #1 0xd10adb in mdb_dn2id /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/dn2id.c:360:9 #2 0xd0798e in mdb_dn2entry /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/dn2entry.c:51:7 #3 0xd4afb5 in mdb_entry_get /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/id2entry.c:336:7 #4 0xa8feb5 in overlay_entry_get_ov /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:376:9 #5 0xaa6dd2 in over_entry_get_rw /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:408:9 #6 0x6a4d9c in be_entry_get_rw /home/ryan/pkg/openldap/openldap/servers/slapd/backend.c:1436:10 #7 0xdb6298 in memberof_op_modify /home/ryan/pkg/openldap/openldap/servers/slapd/overlays/memberof.c:892:12 #8 0xa931bb in overlay_op_walk /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:681:9 #9 0xaadbea in over_op_func /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:749:7 #10 0xaa5493 in over_op_modify /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:788:9 #11 0x7144f2 in fe_op_modify /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:303:4 #12 0x70b08e in do_modify /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:177:15 #13 0x609ccc in connection_operation /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1134:7 #14 0x602ec3 in connection_read_thread /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1280:14 #15 0xf094de in ldap_int_thread_pool_wrapper /home/ryan/pkg/openldap/openldap/libraries/libldap_r/tpool.c:958:3 #16 0x7f91fc2f40a3 in start_thread /build/glibc-Ir_s5K/glibc-2.19/nptl/pthread_create.c:309 #17 0x7f91fb70604c in clone /build/glibc-Ir_s5K/glibc-2.19/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111 0x602000024967 is located 9 bytes to the left of 10-byte region [0x602000024970,0x60200002497a) allocated by thread T2 here: #0 0x4bb46b in malloc (/usr/local/libexec/slapd+0x4bb46b) #1 0x10e4d7f in ber_memalloc_x /home/ryan/pkg/openldap/openldap/libraries/liblber/memory.c:228:9 #2 0xfc01e1 in ldap_dn2bv_x /home/ryan/pkg/openldap/openldap/libraries/libldap_r/getdn.c:3015:23 #3 0x6e7a37 in dnNormalize /home/ryan/pkg/openldap/openldap/servers/slapd/dn.c:454:8 #4 0x744d1d in ordered_value_normalize /home/ryan/pkg/openldap/openldap/servers/slapd/value.c:587:7 #5 0x7106cd in slap_mods_check /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:627:11 #6 0x70aca3 in do_modify /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:168:15 #7 0x609ccc in connection_operation /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1134:7 #8 0x602ec3 in connection_read_thread /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1280:14 #9 0xf094de in ldap_int_thread_pool_wrapper /home/ryan/pkg/openldap/openldap/libraries/libldap_r/tpool.c:958:3 #10 0x7f91fc2f40a3 in start_thread /build/glibc-Ir_s5K/glibc-2.19/nptl/pthread_create.c:309 Thread T2 created by T1 here: #0 0x4a309f in __interceptor_pthread_create (/usr/local/libexec/slapd+0x4a309f) #1 0xf1d269 in ldap_pvt_thread_create /home/ryan/pkg/openldap/openldap/libraries/libldap_r/thr_posix.c:165:8 #2 0xf05f35 in ldap_pvt_thread_pool_submit /home/ryan/pkg/openldap/openldap/libraries/libldap_r/tpool.c:420:12 #3 0x5e92a5 in slap_listener_activate /home/ryan/pkg/openldap/openldap/servers/slapd/daemon.c:2097:7 #4 0x5e17a4 in slapd_daemon_task /home/ryan/pkg/openldap/openldap/servers/slapd/daemon.c:2728:10 #5 0x7f91fc2f40a3 in start_thread /build/glibc-Ir_s5K/glibc-2.19/nptl/pthread_create.c:309 Thread T1 created by T0 here: #0 0x4a309f in __interceptor_pthread_create (/usr/local/libexec/slapd+0x4a309f) #1 0xf1d269 in ldap_pvt_thread_create /home/ryan/pkg/openldap/openldap/libraries/libldap_r/thr_posix.c:165:8 #2 0x5d2539 in slapd_daemon /home/ryan/pkg/openldap/openldap/servers/slapd/daemon.c:2898:8 #3 0x4e2e3e in main /home/ryan/pkg/openldap/openldap/servers/slapd/main.c:1018:7 #4 0x7f91fb641b44 in __libc_start_main /build/glibc-Ir_s5K/glibc-2.19/csu/libc-start.c:287 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ryan/pkg/openldap/openldap/libraries/liblutil/utils.c:317 lutil_strncopy Shadow bytes around the buggy address: 0x0c047fffc8d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc8e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc8f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc910: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fffc920: fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa 00 02 0x0c047fffc930: fa fa fd fd fa fa fd fd fa fa fd fa fa fa 00 02 0x0c047fffc940: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fd 0x0c047fffc950: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa 0x0c047fffc960: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fffc970: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc ASan internal: fe ==1998==ABORTING

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by hyc＠symas.com 17 Apr '15

17 Apr '15

Dmytro Milinevskyy wrote: > Hello, > we've encountered this problem mainly on Android device. The kernel > sends a fake signal and the baking storage(flash) is not so fast. > I've noticed a typo in my patch for the macro DO_PWRITE in > mdb_env_init_meta. The test should be done for EINTR, not EINVAL. > Do you want me to resend the patch? Yes I already noticed that, so I wrote the patch myself instead of applying yours. Thank you for the context, that's good information. > > Thanks, > Dmytro > > On Fri, Apr 17, 2015 at 7:34 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > milinevskyy(a)gmail.com <mailto:milinevskyy@gmail.com> wrote: > > Full_Name: Dmytro Milinevskyy > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.132.131.166) > > > On linux systems it's common to have system calls interrupted > and restarted. > LMDB should retry pwrites to avoid "false" failures. > > > In practice, writes to a file are "fast" and will always write at > least one byte. But we've patched this as suggested, thanks. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- -- 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#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

--047d7bd910b0d34afe0513f14c84 Content-Type: text/plain; charset=UTF-8 Hello, we've encountered this problem mainly on Android device. The kernel sends a fake signal and the baking storage(flash) is not so fast. I've noticed a typo in my patch for the macro DO_PWRITE in mdb_env_init_meta. The test should be done for EINTR, not EINVAL. Do you want me to resend the patch? Thanks, Dmytro On Fri, Apr 17, 2015 at 7:34 PM, Howard Chu <hyc(a)symas.com> wrote: > milinevskyy(a)gmail.com wrote: > >> Full_Name: Dmytro Milinevskyy >> Version: >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (92.132.131.166) >> >> >> On linux systems it's common to have system calls interrupted and >> restarted. >> LMDB should retry pwrites to avoid "false" failures. >> > > In practice, writes to a file are "fast" and will always write at least > one byte. But we've patched this as suggested, thanks. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --047d7bd910b0d34afe0513f14c84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div>Hello,<br>we've encountered this proble= m mainly on Android device. The kernel sends a fake signal and the baking s= torage(flash) is not so fast.<br>I've noticed a typo in my patch for th= e macro DO_PWRITE in mdb_env_init_meta. The test should be done for EINTR, = not EINVAL.<br></div>Do you want me to resend the patch?<br><br></div>Thank= s,<br></div>Dmytro<br></div><div class=3D"gmail_extra"><br><div class=3D"gm= ail_quote">On Fri, Apr 17, 2015 at 7:34 PM, Howard Chu <span dir=3D"ltr">&l= t;<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>><= /span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:milinevsk= yy(a)gmail.com" target=3D"_blank">milinevskyy(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Dmytro Milinevskyy<br> Version:<br> OS: Linux<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (92.132.131.166)<br> <br> <br> On linux systems it's common to have system calls interrupted and resta= rted.<br> LMDB should retry pwrites to avoid "false" failures.<br> </blockquote> <br> In practice, writes to a file are "fast" and will always write at= least one byte. But we've patched this as suggested, thanks.<span clas= s=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </font></span></blockquote></div><br></div> --047d7bd910b0d34afe0513f14c84--

1 0

(ITS#8107) olcMemberOfDangling: error doesn't prevent adding nonexistent member to group
by rtandy＠sd63.bc.ca 17 Apr '15

17 Apr '15

Full_Name: Ryan Tandy Version: RE24 OS: Ubuntu URL: Submission from: (NULL) (142.31.146.2) $ git describe OPENLDAP_REL_ENG_2_4_40-208-gfd03ec0 $ ./configure --disable-bdb --disable-hdb --enable-memberof && make -j8 && sudo make STRIP= install [...] $ slapadd -Fconfig.d -n0 dn: cn=config objectClass%3ololcGlobal dn: cn=schema,cn=config objectClass: olcSchemaConfig include: file:///usr/local/etc/openldap/schema/core.ldif include: file:///usr/local/etc/openldap/schema/cosine.ldif dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDbDirectory: data.d olcSuffix: dc=example,dc=com olcDbIndex: objectClass eq olcAccess: to * by dn="cn=admin,dc=example,dc=com" write by * read dn: olcOverlay=memberof,olcDatabase={1}mdb,cn=config objectClass: olcMemberOf olcMemberOfDangling: error $ slapadd -Fconfig.d dn: dc=example,dc=com objectClass: domain dn: cn=admin,dc=example,dc=com objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: secret $ /usr/local/libexec/slapd -h ldap://:9000 -Fnfigig.d $ ldapadd -H ldap://:9000 -x -D cn=admin,dc=example,dc=com -w secret dn: cn=testgroup,dc=example,dc=com objectClass: groupOfNames member: cn=nonexistent adding new entry "cn=testgroup,dc=example,dc=com" ldap_add: Constraint violation (19) additional info: adding non-existing object as group member $ ldapsearch -H ldap://:9000 -x -b cn=testgroup,dc=example,dc=com # extended LDIF # # LDAPv3 # base <cn=testgroup,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL%%2# # search result search: 2 result: 32 No such object matchedDN: dc=example,dc=com # numResponses: 1 OK, that's fine. The new entry was rejected. $ ldapadd -H ldap://:9000 -x -D cn=admin,dc=example,dc=com -w secret dn: cn=testgroup,dc=example,dc=com objectClass: groupOfNames member: cn=admin,dc=example,dc=com adding new entry "cn=testgroup,dc=example,dc=com" dn: cn=testgroup,dc=example,dc=com changetype: modify add: member member: cn=nonexistent modifying entry "cn=testgroup,dc=example,dc=com" ldap_modify: Constraint violation (19) additional info: adding non-existing object as group member $ ldapsearch -H ldap://:9000 -x -b cn=testgroup,dc=example,dc=com # extended LDIF # # LDAPv3 # base <cn=testgroup,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # testgroup, example.com dn: cn=testgroup,dc=example,dc=com objectClass: groupOfNames member: cn=admin,dc=example,dc=com member: cn=nonexistent cn: testgroup # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 This is unexpected. The member addition was rejected, but somehow the modification went through anyway? Seems like something spooky is going on here... 903 9%9 send_ldap_result( op, rs ); (gdb) p rc $4 = 19 (gdb) n 55315ce0 send_ldap_result: conn=1001 op=2 p=3 55315ce0 send_ldap_response: msgid=3 tag=103 err=19 ber_flush2: 56 bytes to sd 12 1214 op->o_dn = save_dn; (gdb) p rc $5 = 32768 (gdb) p rs->sr_err $6 = 19D%D Am I reading that right, send_ldap_result is somehow overwriting rc in the caller? Happens at -O0 as well as -O2.

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by hyc＠symas.com 17 Apr '15

17 Apr '15

milinevskyy(a)gmail.com wrote: > Full_Name: Dmytro Milinevskyy > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.132.131.166) > > > On linux systems it's common to have system calls interrupted and restarted. > LMDB should retry pwrites to avoid "false" failures. In practice, writes to a file are "fast" and will always write at least one byte. But we've patched this as suggested, thanks. -- -- 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

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