openldap-bugs February 2011

openldap-bugs@openldap.org

35 participants
158 discussions

(ITS#6822) overlays on cn=config break back-config's default acl
by ralf＠OpenLDAP.org 02 Feb '11

02 Feb '11

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.241.48) Submitted by: ralf By default, if no ACLs are defined for back-config, back-config creates default ACL to deny access to everybody (see config_back_db_open() in bconfig.c), instead of just using the global ACLs as other backends do. If however an overlay in configured for cn=config (e.g. syncprov) this default-deny ACL is not present. I am currently working on a fix for this.

1 0

Re: (ITS#6821) ldap modify with ndb backend causes segfault
by anderson＠vailsys.com 02 Feb '11

02 Feb '11

Program terminated with signal 11, Segmentation fault. #0 0x00000000004c4a2d in ndb_modify_internal (op=0x1ae74c0, NA=0x0, text=<value optimized out>, textbuf=<value optimized out>, textlen=<value optimized out>) at modify.cpp:416 416 for ( i=0; i<nai; i++ ) { (gdb) bt #0 0x00000000004c4a2d in ndb_modify_internal (op=0x1ae74c0, NA=0x0, text=<value optimized out>, textbuf=<value optimized out>, textlen=<value optimized out>) at modify.cpp:416 #1 0x00000000004c5605 in ndb_back_modify (op=0x1bcd940, rs=0x7f1d3a7bd9f0) at modify.cpp:646 #2 0x0000000000450141 in fe_op_modify (op=0x1bcd940, rs=0x7f1d3a7bd9f0) at modify.c:211 #3 0x0000000000450a96 in do_modify (op=0x1bcd940, rs=0x7f1d3a7bd9f0) at modify.c:142 #4 0x0000000000437b78 in connection_operation (ctx=0x7f1d3a7bdb50, arg_v=<value optimized out>) at connection.c:1129 #5 0x000000000043876d in syslog (ctx=<value optimized out>, argv=<value optimized out>) at /usr/include/bits/syslog.h:32 #6 connection_read (ctx=<value optimized out>, argv=<value optimized out>) at connection.c:1429 #7 connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at connection.c:1242 #8 0x00007f1d3ef30b48 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007f1d3d72b9ca in start_thread () from /lib/libpthread.so.0 #10 0x00007f1d3bef370d in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () On Wed, 2011-02-02 at 01:47 -0800, Howard Chu wrote: > This trace has no line numbers, so it's not very useful. Make sure you > use an > unstripped binary. > > > Program terminated with signal 11, Segmentation fault. > > #0 0x00000000004c491d in ndb_modify_internal () > > (gdb) bt > > #0 0x00000000004c491d in ndb_modify_internal () > > #1 0x00000000004c5515 in ndb_back_modify () > > #2 0x0000000000450001 in fe_op_modify () > > #3 0x0000000000450956 in do_modify () > > #4 0x0000000000437ad8 in ?? () > > #5 0x00000000004386cd in ?? () > > #6 0x00007ff79450ab08 in ldap_int_thread_pool_wrapper (xpool=<value > optimized > > out>) at tpool.c:685 > > #7 0x00007ff792d059ca in start_thread () from /lib/libpthread.so.0 > > #8 0x00007ff7914cd70d in clone () from /lib/libc.so.6 > > #9 0x0000000000000000 in ?? ()

1 0

Re: (ITS#6821) ldap modify with ndb backend causes segfault
by hyc＠symas.com 02 Feb '11

02 Feb '11

anderson(a)vailsys.com wrote: > Full_Name: Nathanael Anderson > Version: head > OS: linux (Ubuntu 10.10) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.63.156.11) > > > when doing a modify operation against head results in this segfault > > the same operation works fine against the bdb backend. > > I don't currently have an ldif example, as I noticed this issue when using > phpldapadmin to modify an entry. If an ldif is needed let me know and i'll work > on making one that crashes in the same way. > > these schema's are loaded in the config: > > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/ppolicy.schema > include /usr/local/etc/openldap/schema/nis.schema > > compiled with these options: > ./configure --enable-ndb --enable-passwd --enable-modules --enable-slp > --enable-crypt --enable-overlays --enable-dynamic --enable-syslog --enable-debug > --enable-auditlog --disable-cleartext --enable-wrappers --enable-ppolicy > > Back Trace: This trace has no line numbers, so it's not very useful. Make sure you use an unstripped binary. > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004c491d in ndb_modify_internal () > (gdb) bt > #0 0x00000000004c491d in ndb_modify_internal () > #1 0x00000000004c5515 in ndb_back_modify () > #2 0x0000000000450001 in fe_op_modify () > #3 0x0000000000450956 in do_modify () > #4 0x0000000000437ad8 in ?? () > #5 0x00000000004386cd in ?? () > #6 0x00007ff79450ab08 in ldap_int_thread_pool_wrapper (xpool=<value optimized > out>) at tpool.c:685 > #7 0x00007ff792d059ca in start_thread () from /lib/libpthread.so.0 > #8 0x00007ff7914cd70d in clone () from /lib/libc.so.6 > #9 0x0000000000000000 in ?? () > > Debug -1: > > ldap_read: want=348, got=348 > 0000: 82 01 59 04 26 75 69 64 3d 61 74 75 73 65 72 2c ..Y.&uid=atuser, > 0010: 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 3d 76 61 69 ou=people,dc=vai > 0020: 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 82 01 2d 30 lsys,dc=com0..-0 > 0030: 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 65 ....0...gidnumbe > 0040: 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 26 r1...10000+...0& > 0050: 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79 31 ..homedirectory1 > 0060: 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 2f .../export/home/ > 0070: 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a 6c atuser0....0...l > 0080: 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 69 oginshell1.../bi > 0090: 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b 6f n/bash01...0,..o > 00a0: 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 6e bjectclass1...in > 00b0: 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f 73 etOrgPerson..pos > 00c0: 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 72 ixAccount0w...0r > 00d0: 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 62 ..userpassword1b > 00e0: 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 38 .`{SHA512}CxD0B8 > 00f0: 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 79 UEbrLZO9CzdXwLxy > 0100: 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 4b /dA+XhB90k+6NJYK > 0110: 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b 55 V/msYyAzc2EjegkU > 0120: 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 76 BKn+HbP/JvkCjv0v > 0130: 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d 77 JhaMnFHE+n0WPgmw > 0140: 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e 75 ==0....0...uidnu > 0150: 6d 62 65 72 31 06 04 04 31 30 30 30 mber1...1000 > ber_get_next: tag 0x30 len 352 contents: > ber_dump: buf=0x26c2380 ptr=0x26c2380 end=0x26c24e0 len=352 > 0000: 02 01 06 66 82 01 59 04 26 75 69 64 3d 61 74 75 ...f..Y.&uid=atu > 0010: 73 65 72 2c 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 ser,ou=people,dc > 0020: 3d 76 61 69 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 =vailsys,dc=com0 > 0030: 82 01 2d 30 18 0a 01 02 30 13 04 09 67 69 64 6e ..-0....0...gidn > 0040: 75 6d 62 65 72 31 06 04 04 31 30 30 30 30 2b 0a umber1...10000+. > 0050: 01 02 30 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 ..0&..homedirect > 0060: 6f 72 79 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 ory1.../export/h > 0070: 6f 6d 65 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 ome/atuser0....0 > 0080: 19 04 0a 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 ...loginshell1.. > 0090: 09 2f 62 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 ./bin/bash01...0 > 00a0: 2c 04 0b 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d ,..objectclass1. > 00b0: 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 ..inetOrgPerson. > 00c0: 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 30 77 0a .posixAccount0w. > 00d0: 01 02 30 72 04 0c 75 73 65 72 70 61 73 73 77 6f ..0r..userpasswo > 00e0: 72 64 31 62 04 60 7b 53 48 41 35 31 32 7d 43 78 rd1b.`{SHA512}Cx > 00f0: 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 D0B8UEbrLZO9CzdX > 0100: 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 wLxy/dA+XhB90k+6 > 0110: 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a NJYKV/msYyAzc2Ej > 0120: 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 egkUBKn+HbP/JvkC > 0130: 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 jv0vJhaMnFHE+n0W > 0140: 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 Pgmw==0....0...u > 0150: 69 64 6e 75 6d 62 65 72 31 06 04 04 31 30 30 30 idnumber1...1000 > op tag 0x66, time 1296600090 > ber_get_next > ldap_read: want=8 error=Resource temporarily unavailable > conn=1002 op=5 do_modify > ber_scanf fmt ({m) ber: > ber_dump: buf=0x26c2380 ptr=0x26c2383 end=0x26c24e0 len=349 > 0000: 66 82 01 59 04 26 75 69 64 3d 61 74 75 73 65 72 f..Y.&uid=atuser > 0010: 2c 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 3d 76 61 ,ou=people,dc=va > 0020: 69 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 82 01 2d ilsys,dc=com0..- > 0030: 30 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 0....0...gidnumb > 0040: 65 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 er1...10000+...0 > 0050: 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79&..homedirectory > 0060: 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 1.../export/home > 0070: 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a /atuser0....0... > 0080: 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 loginshell1.../b > 0090: 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b in/bash01...0,.. > 00a0: 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 objectclass1...i > 00b0: 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f netOrgPerson..po > 00c0: 73 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 sixAccount0w...0 > 00d0: 72 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 r..userpassword1 > 00e0: 62 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 b.`{SHA512}CxD0B > 00f0: 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 8UEbrLZO9CzdXwLx > 0100: 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 y/dA+XhB90k+6NJY > 0110: 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b KV/msYyAzc2Ejegk > 0120: 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 UBKn+HbP/JvkCjv0 > 0130: 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d vJhaMnFHE+n0WPgm > 0140: 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e w==0....0...uidn > 0150: 75 6d 62 65 72 31 06 04 04 31 30 30 30 umber1...1000 > conn=1002 op=5 do_modify: dn (uid=atuser,ou=people,dc=vailsys,dc=com) > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c23b3 end=0x26c24e0 len=301 > 0000: 30 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 0....0...gidnumb > 0010: 65 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 er1...10000+...0 > 0020: 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79&..homedirectory > 0030: 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 1.../export/home > 0040: 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a /atuser0....0... > 0050: 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 loginshell1.../b > 0060: 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b in/bash01...0,.. > 0070: 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 objectclass1...i > 0080: 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f netOrgPerson..po > 0090: 73 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 sixAccount0w...0 > 00a0: 72 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 r..userpassword1 > 00b0: 62 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 b.`{SHA512}CxD0B > 00c0: 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 8UEbrLZO9CzdXwLx > 00d0: 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 y/dA+XhB90k+6NJY > 00e0: 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b KV/msYyAzc2Ejegk > 00f0: 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 UBKn+HbP/JvkCjv0 > 0100: 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d vJhaMnFHE+n0WPgm > 0110: 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e w==0....0...uidn > 0120: 75 6d 62 65 72 31 06 04 04 31 30 30 30 umber1...1000 > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c23cd end=0x26c24e0 len=275 > 0000: 30 2b 0a 01 02 30 26 04 0d 68 6f 6d 65 64 69 72 0+...0&..homedir > 0010: 65 63 74 6f 72 79 31 15 04 13 2f 65 78 70 6f 72 ectory1.../expor > 0020: 74 2f 68 6f 6d 65 2f 61 74 75 73 65 72 30 1e 0a t/home/atuser0.. > 0030: 01 02 30 19 04 0a 6c 6f 67 69 6e 73 68 65 6c 6c ..0...loginshell > 0040: 31 0b 04 09 2f 62 69 6e 2f 62 61 73 68 30 31 0a 1.../bin/bash01. > 0050: 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 6c 61 73 ..0,..objectclas > 0060: 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 s1...inetOrgPers > 0070: 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 on..posixAccount > 0080: 30 77 0a 01 02 30 72 04 0c 75 73 65 72 70 61 73 0w...0r..userpas > 0090: 73 77 6f 72 64 31 62 04 60 7b 53 48 41 35 31 32 sword1b.`{SHA512 > 00a0: 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 }CxD0B8UEbrLZO9C > 00b0: 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 zdXwLxy/dA+XhB90 > 00c0: 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 k+6NJYKV/msYyAzc > 00d0: 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 2EjegkUBKn+HbP/J > 00e0: 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b vkCjv0vJhaMnFHE+ > 00f0: 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 n0WPgmw==0....0. > 0100: 04 09 75 69 64 6e 75 6d 62 65 72 31 06 04 04 31 ..uidnumber1...1 > 0110: 30 30 30 000 > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c23fa end=0x26c24e0 len=230 > 0000: 30 1e 0a 01 02 30 19 04 0a 6c 6f 67 69 6e 73 68 0....0...loginsh > 0010: 65 6c 6c 31 0b 04 09 2f 62 69 6e 2f 62 61 73 68 ell1.../bin/bash > 0020: 30 31 0a 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 01...0,..objectc > 0030: 6c 61 73 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 lass1...inetOrgP > 0040: 65 72 73 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f erson..posixAcco > 0050: 75 6e 74 30 77 0a 01 02 30 72 04 0c 75 73 65 72 unt0w...0r..user > 0060: 70 61 73 73 77 6f 72 64 31 62 04 60 7b 53 48 41 password1b.`{SHA > 0070: 35 31 32 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 512}CxD0B8UEbrLZ > 0080: 4f 39 43 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 O9CzdXwLxy/dA+Xh > 0090: 42 39 30 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 B90k+6NJYKV/msYy > 00a0: 41 7a 63 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 Azc2EjegkUBKn+Hb > 00b0: 50 2f 4a 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 P/JvkCjv0vJhaMnF > 00c0: 48 45 2b 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 HE+n0WPgmw==0... > 00d0: 02 30 13 04 09 75 69 64 6e 75 6d 62 65 72 31 06 .0...uidnumber1. > 00e0: 04 04 31 30 30 30 ..1000 > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c241a end=0x26c24e0 len=198 > 0000: 30 31 0a 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 01...0,..objectc > 0010: 6c 61 73 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 lass1...inetOrgP > 0020: 65 72 73 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f erson..posixAcco > 0030: 75 6e 74 30 77 0a 01 02 30 72 04 0c 75 73 65 72 unt0w...0r..user > 0040: 70 61 73 73 77 6f 72 64 31 62 04 60 7b 53 48 41 password1b.`{SHA > 0050: 35 31 32 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 512}CxD0B8UEbrLZ > 0060: 4f 39 43 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 O9CzdXwLxy/dA+Xh > 0070: 42 39 30 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 B90k+6NJYKV/msYy > 0080: 41 7a 63 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 Azc2EjegkUBKn+Hb > 0090: 50 2f 4a 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 P/JvkCjv0vJhaMnF > 00a0: 48 45 2b 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 HE+n0WPgmw==0... > 00b0: 02 30 13 04 09 75 69 64 6e 75 6d 62 65 72 31 06 .0...uidnumber1. > 00c0: 04 04 31 30 30 30 ..1000 > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c244d end=0x26c24e0 len=147 > 0000: 30 77 0a 01 02 30 72 04 0c 75 73 65 72 70 61 73 0w...0r..userpas > 0010: 73 77 6f 72 64 31 62 04 60 7b 53 48 41 35 31 32 sword1b.`{SHA512 > 0020: 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 }CxD0B8UEbrLZO9C > 0030: 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 zdXwLxy/dA+XhB90 > 0040: 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 k+6NJYKV/msYyAzc > 0050: 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 2EjegkUBKn+HbP/J > 0060: 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b vkCjv0vJhaMnFHE+ > 0070: 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 n0WPgmw==0....0. > 0080: 04 09 75 69 64 6e 75 6d 62 65 72 31 06 04 04 31 ..uidnumber1...1 > 0090: 30 30 30 000 > ber_scanf fmt ({e{m[W]}}) ber: > ber_dump: buf=0x26c2380 ptr=0x26c24c6 end=0x26c24e0 len=26 > 0000: 30 18 0a 01 02 30 13 04 09 75 69 64 6e 75 6d 62 0....0...uidnumb > 0010: 65 72 31 06 04 04 31 30 30 30 er1...1000 >>>> dnPrettyNormal:<uid=atuser,ou=people,dc=vailsys,dc=com> > => ldap_bv2dn(uid=atuser,ou=people,dc=vailsys,dc=com,0) > <= ldap_bv2dn(uid=atuser,ou=people,dc=vailsys,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(uid=atuser,ou=people,dc=vailsys,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(uid=atuser,ou=people,dc=vailsys,dc=com)=0 > <<< dnPrettyNormal:<uid=atuser,ou=people,dc=vailsys,dc=com>, > <uid=atuser,ou=people,dc=vailsys,dc=com> > conn=1002 op=5 modifications: > replace: gidnumber > one value, length 4 > replace: homedirectory > one value, length 19 > replace: loginshell > one value, length 9 > replace: objectclass > multiple values > replace: userpassword > one value, length 96 > replace: uidnumber > one value, length 4 > conn=1002 op=5 MOD dn="uid=atuser,ou=people,dc=vailsys,dc=com" > daemon: activity on 1 descriptor > daemon: activity on: > daemon: epoll: listen=7 active_threads=0 tvp=NULL > daemon: epoll: listen=8 active_threads=0 tvp=NULL > conn=1002 op=5 MOD attr=gidnumber homedirectory loginshell objectclass > userpassword uidnumber > ndb_back_modify: uid=atuser,ou=people,dc=vailsys,dc=com > slap_queue_csn: queing 0x7fe9b3e28c50 20110201224130.989215Z#000000#000#000000 > conn=1002 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text= >>>> dnNormalize:<cn=admin,dc=vailsys,dc=com> > => ldap_bv2dn(cn=admin,dc=vailsys,dc=com,0) > <= ldap_bv2dn(cn=admin,dc=vailsys,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(cn=admin,dc=vailsys,dc=com)=0 > <<< dnNormalize:<cn=admin,dc=vailsys,dc=com> >>>> dnNormalize:<cn=admin,dc=vailsys,dc=com> > => ldap_bv2dn(cn=admin,dc=vailsys,dc=com,0) > <= ldap_bv2dn(cn=admin,dc=vailsys,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(cn=admin,dc=vailsys,dc=com)=0 > <<< dnNormalize:<cn=admin,dc=vailsys,dc=com> > ndb_modify_internal: 0x00006d61: uid=atuser,ou=people,dc=vailsys,dc=com > <= acl_access_allowed: granted to database root > ndb_modify_internal: replace gidNumber > ndb_modify_internal: replace homeDirectory > ndb_modify_internal: replace loginShell > ndb_modify_internal: replace objectClass > ndb_modify_internal: replace userPassword > ndb_modify_internal: replace uidNumber > ndb_modify_internal: replace entryCSN > ndb_modify_internal: replace modifiersName > ndb_modify_internal: replace modifyTimestamp > oc_check_required entry (uid=atuser,ou=people,dc=vailsys,dc=com), objectClass > "inetOrgPerson" > oc_check_required entry (uid=atuser,ou=people,dc=vailsys,dc=com), objectClass > "posixAccount" > oc_check_allowed type "sn" > oc_check_allowed type "cn" > oc_check_allowed type "givenName" > oc_check_allowed type "uid" > oc_check_allowed type "structuralObjectClass" > oc_check_allowed type "entryUUID" > oc_check_allowed type "creatorsName" > oc_check_allowed type "createTimestamp" > oc_check_allowed type "gidNumber" > oc_check_allowed type "homeDirectory" > oc_check_allowed type "loginShell" > oc_check_allowed type "objectClass" > oc_check_allowed type "userPassword" > oc_check_allowed type "uidNumber" > oc_check_allowed type "entryCSN" > oc_check_allowed type "modifiersName" > oc_check_allowed type "modifyTimestamp" > Segmentation fault (core dumped) > > -- -- 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#6652) accesslog anomaly in db drop/re-import
by marco.pizzoli＠gmail.com 02 Feb '11

02 Feb '11

--000e0cd157581b9a96049b48f417 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Done. The slapcat/drop/slapadd procedure went fine. Thanks Marco On Tue, Feb 1, 2011 at 4:53 PM, Marco Pizzoli <marco.pizzoli(a)gmail.com>wrot= e: > Ok, I re-downloaded the source tree and now the accesslog.c file is > updated. > > I started the daemon and tomorrow I will re-try the drop/import. > > Thanks > Marco Pizzoli > > > On Tue, Feb 1, 2011 at 4:41 PM, Hallvard B Furuseth < > h.b.furuseth(a)usit.uio.no> wrote: > >> marco.pizzoli(a)gmail.com writes: >> > I downloaded the HEAD repository, compiled and tried the import. Same >> > problem on the same line. >> > (...) >> > Had I downloaded the wrong repository? >> >> Probably not, but you can check CVS/Root - it should contain >> :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP >> >> However, try again now. The public CVS repository it is regularly >> synced with the main repository, but you may have updated from it >> before the patch reached it. >> >> > I went to see the version of the source accesslog.c and saw this line = on >> top >> > of it: >> > /* accesslog.c - log operations for audit/history purposes */ >> > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 = * >> > 2011/01/26* 23:23:34 quanah Exp $ */ >> >> That from the release branch, which has not merged this patch. >> >> HEAD is the main branch used for development, currently with accesslog >> 1.115. >> >> -- >> Hallvard >> > > > > -- > _________________________________________ > Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. > Jim Morrison > --=20 _________________________________________ Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison --000e0cd157581b9a96049b48f417 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Done. <br>The slapcat/drop/slapadd procedure went fine.<br><br>Thanks<br>= =A0=A0=A0=A0=A0=A0 Marco<br><br><br><br><div class=3D"gmail_quote">On Tue, = Feb 1, 2011 at 4:53 PM, Marco Pizzoli <span dir=3D"ltr"><<a href=3D"mail= to:marco.pizzoli@gmail.com">marco.pizzoli(a)gmail.com</a>></span> wrote:<b= r> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Ok, I re-download= ed the source tree and now the accesslog.c file is updated.<br><br>I starte= d the daemon and tomorrow I will re-try the drop/import.<br> <br>Thanks<br><font color=3D"#888888">=A0=A0=A0=A0=A0 Marco Pizzoli</font><= div><div></div><div class=3D"h5"><br><br><div class=3D"gmail_quote">On Tue,= Feb 1, 2011 at 4:41 PM, Hallvard B Furuseth <span dir=3D"ltr"><<a href= =3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth(a)usit.ui= o.no</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><a href=3D"m= ailto:marco.pizzoli@gmail.com" target=3D"_blank">marco.pizzoli(a)gmail.com</a= > writes:<br> > I downloaded the HEAD repository, compiled and tried the import. Same<= br> > problem on the same line.<br> </div>> (...)<br> <div>> Had I downloaded the wrong repository?<br> <br> </div>Probably not, but you can check CVS/Root - it should contain<br> =A0 =A0 =A0 =A0:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP<br> <br> However, try again now. =A0The public CVS repository it is regularly<br> synced with the main repository, but you may have updated from it<br> before the patch reached it.<br> <div><br> > I went to see the version of the source accesslog.c and saw this line = on top<br> > of it:<br> > /* accesslog.c - log operations for audit/history purposes */<br> > /* $OpenLDAP: pkg/ldap/servers/slapd/overlays/accesslog.c,v 1.37.2.34 = *<br> > 2011/01/26* 23:23:34 quanah Exp $ */<br> <br> </div>That from the release branch, which has not merged this patch.<br> <br> HEAD is the main branch used for development, currently with accesslog<br> 1.115.<br> <br> --<br> <font color=3D"#888888">Hallvard<br> </font></blockquote></div><br><br clear=3D"all"><br></div></div><div><div><= /div><div class=3D"h5">-- <br>_________________________________________<br>= Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi.<br>=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison<br> <div style=3D"padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hi= dden; word-wrap: break-word; color: black; font-size: 10px; text-align: lef= t; line-height: 130%;"> </div> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>___________= ______________________________<br>Non =E8 forte chi non cade, ma chi cadend= o ha la forza di rialzarsi.<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim = Morrison<br> <div style=3D"visibility: hidden; left: -5000px; position: absolute; z-inde= x: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden;= word-wrap: break-word; color: black; font-size: 10px; text-align: left; li= ne-height: 130%;" id=3D"avg_ls_inline_popup"> </div> --000e0cd157581b9a96049b48f417--

1 0

(ITS#6821) ldap modify with ndb backend causes segfault
by anderson＠vailsys.com 01 Feb '11

01 Feb '11

Full_Name: Nathanael Anderson Version: head OS: linux (Ubuntu 10.10) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.63.156.11) when doing a modify operation against head results in this segfault the same operation works fine against the bdb backend. I don't currently have an ldif example, as I noticed this issue when using phpldapadmin to modify an entry. If an ldif is needed let me know and i'll work on making one that crashes in the same way. these schema's are loaded in the config: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/ppolicy.schema include /usr/local/etc/openldap/schema/nis.schema compiled with these options: ./configure --enable-ndb --enable-passwd --enable-modules --enable-slp --enable-crypt --enable-overlays --enable-dynamic --enable-syslog --enable-debug --enable-auditlog --disable-cleartext --enable-wrappers --enable-ppolicy Back Trace: Program terminated with signal 11, Segmentation fault. #0 0x00000000004c491d in ndb_modify_internal () (gdb) bt #0 0x00000000004c491d in ndb_modify_internal () #1 0x00000000004c5515 in ndb_back_modify () #2 0x0000000000450001 in fe_op_modify () #3 0x0000000000450956 in do_modify () #4 0x0000000000437ad8 in ?? () #5 0x00000000004386cd in ?? () #6 0x00007ff79450ab08 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #7 0x00007ff792d059ca in start_thread () from /lib/libpthread.so.0 #8 0x00007ff7914cd70d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Debug -1: ldap_read: want=348, got=348 0000: 82 01 59 04 26 75 69 64 3d 61 74 75 73 65 72 2c ..Y.&uid=atuser, 0010: 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 3d 76 61 69 ou=people,dc=vai 0020: 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 82 01 2d 30 lsys,dc=com0..-0 0030: 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 65 ....0...gidnumbe 0040: 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 26 r1...10000+...0& 0050: 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79 31 ..homedirectory1 0060: 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 2f .../export/home/ 0070: 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a 6c atuser0....0...l 0080: 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 69 oginshell1.../bi 0090: 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b 6f n/bash01...0,..o 00a0: 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 6e bjectclass1...in 00b0: 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f 73 etOrgPerson..pos 00c0: 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 72 ixAccount0w...0r 00d0: 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 62 ..userpassword1b 00e0: 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 38 .`{SHA512}CxD0B8 00f0: 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 79 UEbrLZO9CzdXwLxy 0100: 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 4b /dA+XhB90k+6NJYK 0110: 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b 55 V/msYyAzc2EjegkU 0120: 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 76 BKn+HbP/JvkCjv0v 0130: 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d 77 JhaMnFHE+n0WPgmw 0140: 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e 75 ==0....0...uidnu 0150: 6d 62 65 72 31 06 04 04 31 30 30 30 mber1...1000 ber_get_next: tag 0x30 len 352 contents: ber_dump: buf=0x26c2380 ptr=0x26c2380 end=0x26c24e0 len=352 0000: 02 01 06 66 82 01 59 04 26 75 69 64 3d 61 74 75 ...f..Y.&uid=atu 0010: 73 65 72 2c 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 ser,ou=people,dc 0020: 3d 76 61 69 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 =vailsys,dc=com0 0030: 82 01 2d 30 18 0a 01 02 30 13 04 09 67 69 64 6e ..-0....0...gidn 0040: 75 6d 62 65 72 31 06 04 04 31 30 30 30 30 2b 0a umber1...10000+. 0050: 01 02 30 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 ..0&..homedirect 0060: 6f 72 79 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 ory1.../export/h 0070: 6f 6d 65 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 ome/atuser0....0 0080: 19 04 0a 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 ...loginshell1.. 0090: 09 2f 62 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 ./bin/bash01...0 00a0: 2c 04 0b 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d ,..objectclass1. 00b0: 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 ..inetOrgPerson. 00c0: 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 30 77 0a .posixAccount0w. 00d0: 01 02 30 72 04 0c 75 73 65 72 70 61 73 73 77 6f ..0r..userpasswo 00e0: 72 64 31 62 04 60 7b 53 48 41 35 31 32 7d 43 78 rd1b.`{SHA512}Cx 00f0: 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 D0B8UEbrLZO9CzdX 0100: 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 wLxy/dA+XhB90k+6 0110: 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a NJYKV/msYyAzc2Ej 0120: 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 egkUBKn+HbP/JvkC 0130: 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 jv0vJhaMnFHE+n0W 0140: 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 Pgmw==0....0...u 0150: 69 64 6e 75 6d 62 65 72 31 06 04 04 31 30 30 30 idnumber1...1000 op tag 0x66, time 1296600090 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=1002 op=5 do_modify ber_scanf fmt ({m) ber: ber_dump: buf=0x26c2380 ptr=0x26c2383 end=0x26c24e0 len=349 0000: 66 82 01 59 04 26 75 69 64 3d 61 74 75 73 65 72 f..Y.&uid=atuser 0010: 2c 6f 75 3d 70 65 6f 70 6c 65 2c 64 63 3d 76 61 ,ou=people,dc=va 0020: 69 6c 73 79 73 2c 64 63 3d 63 6f 6d 30 82 01 2d ilsys,dc=com0..- 0030: 30 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 0....0...gidnumb 0040: 65 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 er1...10000+...0 0050: 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79 &..homedirectory 0060: 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 1.../export/home 0070: 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a /atuser0....0... 0080: 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 loginshell1.../b 0090: 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b in/bash01...0,.. 00a0: 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 objectclass1...i 00b0: 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f netOrgPerson..po 00c0: 73 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 sixAccount0w...0 00d0: 72 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 r..userpassword1 00e0: 62 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 b.`{SHA512}CxD0B 00f0: 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 8UEbrLZO9CzdXwLx 0100: 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 y/dA+XhB90k+6NJY 0110: 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b KV/msYyAzc2Ejegk 0120: 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 UBKn+HbP/JvkCjv0 0130: 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d vJhaMnFHE+n0WPgm 0140: 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e w==0....0...uidn 0150: 75 6d 62 65 72 31 06 04 04 31 30 30 30 umber1...1000 conn=1002 op=5 do_modify: dn (uid=atuser,ou=people,dc=vailsys,dc=com) ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c23b3 end=0x26c24e0 len=301 0000: 30 18 0a 01 02 30 13 04 09 67 69 64 6e 75 6d 62 0....0...gidnumb 0010: 65 72 31 06 04 04 31 30 30 30 30 2b 0a 01 02 30 er1...10000+...0 0020: 26 04 0d 68 6f 6d 65 64 69 72 65 63 74 6f 72 79 &..homedirectory 0030: 31 15 04 13 2f 65 78 70 6f 72 74 2f 68 6f 6d 65 1.../export/home 0040: 2f 61 74 75 73 65 72 30 1e 0a 01 02 30 19 04 0a /atuser0....0... 0050: 6c 6f 67 69 6e 73 68 65 6c 6c 31 0b 04 09 2f 62 loginshell1.../b 0060: 69 6e 2f 62 61 73 68 30 31 0a 01 02 30 2c 04 0b in/bash01...0,.. 0070: 6f 62 6a 65 63 74 63 6c 61 73 73 31 1d 04 0d 69 objectclass1...i 0080: 6e 65 74 4f 72 67 50 65 72 73 6f 6e 04 0c 70 6f netOrgPerson..po 0090: 73 69 78 41 63 63 6f 75 6e 74 30 77 0a 01 02 30 sixAccount0w...0 00a0: 72 04 0c 75 73 65 72 70 61 73 73 77 6f 72 64 31 r..userpassword1 00b0: 62 04 60 7b 53 48 41 35 31 32 7d 43 78 44 30 42 b.`{SHA512}CxD0B 00c0: 38 55 45 62 72 4c 5a 4f 39 43 7a 64 58 77 4c 78 8UEbrLZO9CzdXwLx 00d0: 79 2f 64 41 2b 58 68 42 39 30 6b 2b 36 4e 4a 59 y/dA+XhB90k+6NJY 00e0: 4b 56 2f 6d 73 59 79 41 7a 63 32 45 6a 65 67 6b KV/msYyAzc2Ejegk 00f0: 55 42 4b 6e 2b 48 62 50 2f 4a 76 6b 43 6a 76 30 UBKn+HbP/JvkCjv0 0100: 76 4a 68 61 4d 6e 46 48 45 2b 6e 30 57 50 67 6d vJhaMnFHE+n0WPgm 0110: 77 3d 3d 30 18 0a 01 02 30 13 04 09 75 69 64 6e w==0....0...uidn 0120: 75 6d 62 65 72 31 06 04 04 31 30 30 30 umber1...1000 ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c23cd end=0x26c24e0 len=275 0000: 30 2b 0a 01 02 30 26 04 0d 68 6f 6d 65 64 69 72 0+...0&..homedir 0010: 65 63 74 6f 72 79 31 15 04 13 2f 65 78 70 6f 72 ectory1.../expor 0020: 74 2f 68 6f 6d 65 2f 61 74 75 73 65 72 30 1e 0a t/home/atuser0.. 0030: 01 02 30 19 04 0a 6c 6f 67 69 6e 73 68 65 6c 6c ..0...loginshell 0040: 31 0b 04 09 2f 62 69 6e 2f 62 61 73 68 30 31 0a 1.../bin/bash01. 0050: 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 6c 61 73 ..0,..objectclas 0060: 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 s1...inetOrgPers 0070: 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 on..posixAccount 0080: 30 77 0a 01 02 30 72 04 0c 75 73 65 72 70 61 73 0w...0r..userpas 0090: 73 77 6f 72 64 31 62 04 60 7b 53 48 41 35 31 32 sword1b.`{SHA512 00a0: 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 }CxD0B8UEbrLZO9C 00b0: 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 zdXwLxy/dA+XhB90 00c0: 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 k+6NJYKV/msYyAzc 00d0: 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 2EjegkUBKn+HbP/J 00e0: 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b vkCjv0vJhaMnFHE+ 00f0: 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 n0WPgmw==0....0. 0100: 04 09 75 69 64 6e 75 6d 62 65 72 31 06 04 04 31 ..uidnumber1...1 0110: 30 30 30 000 ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c23fa end=0x26c24e0 len=230 0000: 30 1e 0a 01 02 30 19 04 0a 6c 6f 67 69 6e 73 68 0....0...loginsh 0010: 65 6c 6c 31 0b 04 09 2f 62 69 6e 2f 62 61 73 68 ell1.../bin/bash 0020: 30 31 0a 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 01...0,..objectc 0030: 6c 61 73 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 lass1...inetOrgP 0040: 65 72 73 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f erson..posixAcco 0050: 75 6e 74 30 77 0a 01 02 30 72 04 0c 75 73 65 72 unt0w...0r..user 0060: 70 61 73 73 77 6f 72 64 31 62 04 60 7b 53 48 41 password1b.`{SHA 0070: 35 31 32 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 512}CxD0B8UEbrLZ 0080: 4f 39 43 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 O9CzdXwLxy/dA+Xh 0090: 42 39 30 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 B90k+6NJYKV/msYy 00a0: 41 7a 63 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 Azc2EjegkUBKn+Hb 00b0: 50 2f 4a 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 P/JvkCjv0vJhaMnF 00c0: 48 45 2b 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 HE+n0WPgmw==0... 00d0: 02 30 13 04 09 75 69 64 6e 75 6d 62 65 72 31 06 .0...uidnumber1. 00e0: 04 04 31 30 30 30 ..1000 ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c241a end=0x26c24e0 len=198 0000: 30 31 0a 01 02 30 2c 04 0b 6f 62 6a 65 63 74 63 01...0,..objectc 0010: 6c 61 73 73 31 1d 04 0d 69 6e 65 74 4f 72 67 50 lass1...inetOrgP 0020: 65 72 73 6f 6e 04 0c 70 6f 73 69 78 41 63 63 6f erson..posixAcco 0030: 75 6e 74 30 77 0a 01 02 30 72 04 0c 75 73 65 72 unt0w...0r..user 0040: 70 61 73 73 77 6f 72 64 31 62 04 60 7b 53 48 41 password1b.`{SHA 0050: 35 31 32 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 512}CxD0B8UEbrLZ 0060: 4f 39 43 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 O9CzdXwLxy/dA+Xh 0070: 42 39 30 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 B90k+6NJYKV/msYy 0080: 41 7a 63 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 Azc2EjegkUBKn+Hb 0090: 50 2f 4a 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 P/JvkCjv0vJhaMnF 00a0: 48 45 2b 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 HE+n0WPgmw==0... 00b0: 02 30 13 04 09 75 69 64 6e 75 6d 62 65 72 31 06 .0...uidnumber1. 00c0: 04 04 31 30 30 30 ..1000 ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c244d end=0x26c24e0 len=147 0000: 30 77 0a 01 02 30 72 04 0c 75 73 65 72 70 61 73 0w...0r..userpas 0010: 73 77 6f 72 64 31 62 04 60 7b 53 48 41 35 31 32 sword1b.`{SHA512 0020: 7d 43 78 44 30 42 38 55 45 62 72 4c 5a 4f 39 43 }CxD0B8UEbrLZO9C 0030: 7a 64 58 77 4c 78 79 2f 64 41 2b 58 68 42 39 30 zdXwLxy/dA+XhB90 0040: 6b 2b 36 4e 4a 59 4b 56 2f 6d 73 59 79 41 7a 63 k+6NJYKV/msYyAzc 0050: 32 45 6a 65 67 6b 55 42 4b 6e 2b 48 62 50 2f 4a 2EjegkUBKn+HbP/J 0060: 76 6b 43 6a 76 30 76 4a 68 61 4d 6e 46 48 45 2b vkCjv0vJhaMnFHE+ 0070: 6e 30 57 50 67 6d 77 3d 3d 30 18 0a 01 02 30 13 n0WPgmw==0....0. 0080: 04 09 75 69 64 6e 75 6d 62 65 72 31 06 04 04 31 ..uidnumber1...1 0090: 30 30 30 000 ber_scanf fmt ({e{m[W]}}) ber: ber_dump: buf=0x26c2380 ptr=0x26c24c6 end=0x26c24e0 len=26 0000: 30 18 0a 01 02 30 13 04 09 75 69 64 6e 75 6d 62 0....0...uidnumb 0010: 65 72 31 06 04 04 31 30 30 30 er1...1000 >>> dnPrettyNormal: <uid=atuser,ou=people,dc=vailsys,dc=com> => ldap_bv2dn(uid=atuser,ou=people,dc=vailsys,dc=com,0) <= ldap_bv2dn(uid=atuser,ou=people,dc=vailsys,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=atuser,ou=people,dc=vailsys,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=atuser,ou=people,dc=vailsys,dc=com)=0 <<< dnPrettyNormal: <uid=atuser,ou=people,dc=vailsys,dc=com>, <uid=atuser,ou=people,dc=vailsys,dc=com> conn=1002 op=5 modifications: replace: gidnumber one value, length 4 replace: homedirectory one value, length 19 replace: loginshell one value, length 9 replace: objectclass multiple values replace: userpassword one value, length 96 replace: uidnumber one value, length 4 conn=1002 op=5 MOD dn="uid=atuser,ou=people,dc=vailsys,dc=com" daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL conn=1002 op=5 MOD attr=gidnumber homedirectory loginshell objectclass userpassword uidnumber ndb_back_modify: uid=atuser,ou=people,dc=vailsys,dc=com slap_queue_csn: queing 0x7fe9b3e28c50 20110201224130.989215Z#000000#000#000000 conn=1002 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text= >>> dnNormalize: <cn=admin,dc=vailsys,dc=com> => ldap_bv2dn(cn=admin,dc=vailsys,dc=com,0) <= ldap_bv2dn(cn=admin,dc=vailsys,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=admin,dc=vailsys,dc=com)=0 <<< dnNormalize: <cn=admin,dc=vailsys,dc=com> >>> dnNormalize: <cn=admin,dc=vailsys,dc=com> => ldap_bv2dn(cn=admin,dc=vailsys,dc=com,0) <= ldap_bv2dn(cn=admin,dc=vailsys,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=admin,dc=vailsys,dc=com)=0 <<< dnNormalize: <cn=admin,dc=vailsys,dc=com> ndb_modify_internal: 0x00006d61: uid=atuser,ou=people,dc=vailsys,dc=com <= acl_access_allowed: granted to database root ndb_modify_internal: replace gidNumber ndb_modify_internal: replace homeDirectory ndb_modify_internal: replace loginShell ndb_modify_internal: replace objectClass ndb_modify_internal: replace userPassword ndb_modify_internal: replace uidNumber ndb_modify_internal: replace entryCSN ndb_modify_internal: replace modifiersName ndb_modify_internal: replace modifyTimestamp oc_check_required entry (uid=atuser,ou=people,dc=vailsys,dc=com), objectClass "inetOrgPerson" oc_check_required entry (uid=atuser,ou=people,dc=vailsys,dc=com), objectClass "posixAccount" oc_check_allowed type "sn" oc_check_allowed type "cn" oc_check_allowed type "givenName" oc_check_allowed type "uid" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "gidNumber" oc_check_allowed type "homeDirectory" oc_check_allowed type "loginShell" oc_check_allowed type "objectClass" oc_check_allowed type "userPassword" oc_check_allowed type "uidNumber" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" Segmentation fault (core dumped)

1 0

Re: (ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com 01 Feb '11

01 Feb '11

I just ran the tests against a build from head, and we don't see the issue anymore. Thanks, Nathanael On Tue, 2011-02-01 at 12:25 -0800, Howard Chu wrote: > Nathanael Anderson wrote: > > I thought I had attached the backtrace when I opened this, sorry. Here > > is the backtrack from 2.4.23. > > > > Compile Options: ./configure --enable-ndb --enable-passwd > > --enable-modules --enable-slp --enable-crypt --enable-overlays > > --enable-dynamic --enable-syslog --enable-debug --enable-auditlog > > --disable-cleartext --enable-wrappers --enable-ppolicy > > > > mysql-cluster-gpl-7.1.9a binary distribution from oracle. > > > > Line 339 in NdbTransaction.cpp didn't refer to a file that I saw. Let me > > know if anything else is needed. > > Thanks, that helped. This is now fixed in HEAD. > > > > > > #0 NdbTransaction::execute (this=0x7fa1ae235659, > > aTypeOfExec=NdbTransaction::Rollback, > > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > > at NdbTransaction.cpp:339 > > 339 NdbTransaction.cpp: No such file or directory. > > in NdbTransaction.cpp > > (gdb) bt > > #0 NdbTransaction::execute (this=0x7fa1ae235659, > > aTypeOfExec=NdbTransaction::Rollback, > > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > > at NdbTransaction.cpp:339 > > #1 0x00000000004f8608 in ndb_back_add () > > #2 0x000000000043ce34 in fe_op_add () > > #3 0x000000000043d695 in do_add () > > #4 0x0000000000435dd9 in ?? () > > #5 0x000000000043662d in ?? () > > #6 0x00007fa1b0f43538 in ldap_int_thread_pool_wrapper (xpool=<value > > optimized out>) at tpool.c:685 > > #7 0x00007fa1af7729ca in start_thread () from /lib/libpthread.so.0 > > #8 0x00007fa1ae27a70d in clone () from /lib/libc.so.6 > > #9 0x0000000000000000 in ?? () > > > >> As always, when you get a core dump, post the gdb backtrace of the dump. Use > >> the most recent release version, and make sure you use a non-optimized debug > >> build with all debug symbols intact. All of these instructions are written on > >> the page where you submit new Issues. > >> > > > > > > > >

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by hyc＠symas.com 01 Feb '11

01 Feb '11

Timo Aaltonen wrote: > On Thu, 20 Jan 2011, Howard Chu wrote: > >> timo.aaltonen(a)aalto.fi wrote: >>> Hi >>> >>> Here's some information that Stephen asked would be of use. There is >>> one forest, one domain, but three sites in the layout. The functional >>> level of the forest and the domain is W2008, but the servers have 2008R2. >>> >>> And the full backtrace of the hung process: >> >>> #3 0x00007f8f652f3bcb in ldap_pvt_thread_mutex_lock >>> (mutex=0x7f8f6553fc80) >>> at /tmp/buildd/openldap-2.4.23/libraries/libldap_r/thr_posix.c:296 >>> No locals. >>> #4 0x00007f8f653010bf in ldap_sasl_interactive_bind_s (ld=0x2117c20, >>> dn=0x0, >>> mechs=0x210d530 "GSSAPI", serverControls=0x0, clientControls=0x0, >>> flags=2, >>> interact=0x7f8f61405120<sdap_sasl_interact>, defaults=0x2124a50) at >>> sasl.c:426 >>> rc = -1921681294 >>> smechs = 0x0 >> >> This particular mutex seems kind of bogus to me; the code is from rev 1.31 in >> June 2001. Perhaps back then it was unsafe to have multiple SASL operations >> outstanding at once; I would expect that was only an issue in the Cyrus 1.5 >> days and it should be safe now with Cyrus 2.x. We should probably just delete >> this mutex. > > Ok, so by doing this: > > --- openldap-2.4.23.orig/libraries/libldap/sasl.c > +++ openldap-2.4.23/libraries/libldap/sasl.c > @@ -421,10 +421,11 @@ > { > int rc; > char *smechs = NULL; > - > +/* > #if defined( LDAP_R_COMPILE )&& defined( HAVE_CYRUS_SASL ) > ldap_pvt_thread_mutex_lock(&ldap_int_sasl_mutex ); > #endif > +*/ > #ifdef LDAP_CONNECTIONLESS > if( LDAP_IS_UDP(ld) ) { > /* Just force it to simple bind, silly to make the user > > -- > > .. the process doesn't hang anymore. But it still doesn't do what it's > supposed to, but that could be a bug in SSSD. I'll investigate further. > > Thanks! > As I noted in a previous followup, it's not clear to me that the Cyrus SASL library is actually safe to use without that mutex. Also, going through your provided backtraces, I see the real issue is that two different requests were active at the same time. I.e., there was an active request that triggered a referral, and an unrelated request. You would also have avoided this issue if you waited for the request that triggered the referrals to complete before issuing any other requests. -- -- 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 01 Feb '11

01 Feb '11

Kartik Subbarao wrote: > On 01/28/2011 08:27 PM, Howard Chu wrote: >>> I'm running into multiple problems here. The core problem seems to be >>> that enabling ppolicy_forward_updates breaks the chaining overlay such that >>> it binds anonymously instead of with SASL EXTERNAL. >> >> That's because your authz-regexp is wrong. You mapped "cn=localhost" but >> when using SASL EXTERNAL, the user's DN is the complete certificate DN. >> In your case, "cn=localhost,o=OpenLDAP,st=Some-State,c=US" >> >> The reason this didn't break replication is because in this test, >> everything has anonymous read access so the consumer was able to pull >> what it needed. > > Hmm, I'm not quite seeing what you're saying here. For example, in > slapd.1.log, *before* ppolicy_forward_updates (olcPPolicyForwardUpdates) > is enabled, I can see the certificate being mapped exactly as I expect it: OK, that's probably a red herring. With your updated cert, I see two issues from the logs - 1) since ppolicy uses the database rootdn to perform the pwdFailuretime update, this is considered a privileged connection. Note from the slapd-ldap(5) manpage that acl-bind is used for root/privileged connections. Your idassert-bind directive had no effect here. The TLS session failed because the acl-bind context had no CA cert configured. Adding an appropriate olcDbACLBind directive got past this issue. 2) since pwdFailuretime is an operational attribute, you need to have manage privilege to update it. With (1) fixed the modify is correctly chained to the provider, but the provider rejects it with Insufficient Access. Changing the ACL in slapd-ppolicy.conf to grant "manage' instead of "write" access fixes that. With both of those corrections, your test script succeeds. Closing this ITS as user config error, there is no software bug here. > > ===== > ==> rewrite_context_apply [depth=1] res={0,'cn=localhost,dc=example,dc=com'} > [rw] authid: "cn=localhost,o=openldap,st=some-state,c=us" -> > "cn=localhost,dc=example,dc=com" > [...] > <==slap_sasl2dn: Converted SASL name to cn=localhost,dc=example,dc=com > slap_sasl_getdn: dn:id converted to cn=localhost,dc=example,dc=com > SASL Canonicalize [conn=1004]: slapAuthcDN="cn=localhost,dc=example,dc=com" > SASL proxy authorize [conn=1004]: > authcid="cn=localhost,o=openldap,st=some-state,c=us" > authzid="cn=localhost,o=openldap,st=some-state,c=us" > conn=1004 op=1 BIND authcid="cn=localhost,o=openldap,st=some-state,c=us" > authzid="cn=localhost,o=openldap,st=some-state,c=us" > SASL Authorize [conn=1004]: proxy authorization allowed authzDN="" > send_ldap_sasl: err=0 len=-1 > conn=1004 op=1 BIND dn="cn=localhost,dc=example,dc=com" mech=EXTERNAL > sasl_ssf=0 ssf=256 > do_bind: SASL/EXTERNAL bind: dn="cn=localhost,dc=example,dc=com" sasl_ssf=0 > ===== > > Based on this, I'm assuming that my authz-regexp is behaving as I'm > intending -- looking for a certificate with "cn=localhost" anywhere in > the subject DN, and mapping that to the DN > cn=localhost,dc=example,dc=com in the directory. > > It's only *after* olcPPolicyForwardUpdates is enabled that the SASL > EXTERNAL authentication stops working. > > Can you help me understand the disconnect between what I'm seeing and > what you're saying? > >> I didn't get this far because your test certificate is now expired. I >> guess I can substitute some other certs and look at it again, but I >> think the core issue is your misconfigured authz-regexp. > > I have updated the expiration date on the certificate and have attached > it to this message. > >> Better to rename your scripts when you modify one of our existing ones. >> E.g. test999-xxxxxx and just create new data files instead of modifying >> ours. > > Ok, will keep this in mind. > > Thanks, > > -Kartik > > > localhost.crt > > > -----BEGIN CERTIFICATE----- > MIICCTCCAXICCQC1gKCIQ2we4DANBgkqhkiG9w0BAQUFADBJMQswCQYDVQQGEwJV > UzETMBEGA1UECBMKU29tZS1TdGF0ZTERMA8GA1UEChMIT3BlbkxEQVAxEjAQBgNV > BAMTCWxvY2FsaG9zdDAeFw0xMTAxMzExNjE1NTdaFw0xMjAxMzExNjE1NTdaMEkx > CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMREwDwYDVQQKEwhPcGVu > TERBUDESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB > iQKBgQCqZU3fA/o/y5gHXxm0JpdMoV64LAOIPgcZTHv4+OkVjoW2gMHT8AMerJzk > Cr07y1JjfeqV1c7sZl6+aqC3H+HLs0cCtXFKPFY9FmoehO9KBksDaH5o2f7h104r > s/xg2cNTDy1dFFJUzMWQIc8TU7+GpjS3gP0/9gNlIyiLdio9LwIDAQABMA0GCSqG > SIb3DQEBBQUAA4GBAGFeVSjX4ZjLmrU7oob4CyoWO2ekeVyldWLjVOUCyeSMae3n > I1/kQ5AbGrJdtQQeLyRhIQKUM2a1AqjPLW1QKPXHnHnbsnzuWmC2C9fIw1C3o0yZ > UBsxlqoA7K486qeyAb6bUO5X2JD2rOng+HL/pgKlo9h8dW23tWj4CEUMepOh > -----END CERTIFICATE----- -- -- 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#6806) Invalid ldapadd crashes openldap with ndb backend
by hyc＠symas.com 01 Feb '11

01 Feb '11

Nathanael Anderson wrote: > I thought I had attached the backtrace when I opened this, sorry. Here > is the backtrack from 2.4.23. > > Compile Options: ./configure --enable-ndb --enable-passwd > --enable-modules --enable-slp --enable-crypt --enable-overlays > --enable-dynamic --enable-syslog --enable-debug --enable-auditlog > --disable-cleartext --enable-wrappers --enable-ppolicy > > mysql-cluster-gpl-7.1.9a binary distribution from oracle. > > Line 339 in NdbTransaction.cpp didn't refer to a file that I saw. Let me > know if anything else is needed. Thanks, that helped. This is now fixed in HEAD. > > > #0 NdbTransaction::execute (this=0x7fa1ae235659, > aTypeOfExec=NdbTransaction::Rollback, > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > at NdbTransaction.cpp:339 > 339 NdbTransaction.cpp: No such file or directory. > in NdbTransaction.cpp > (gdb) bt > #0 NdbTransaction::execute (this=0x7fa1ae235659, > aTypeOfExec=NdbTransaction::Rollback, > abortOption=NdbOperation::DefaultAbortOption, forceSend=0) > at NdbTransaction.cpp:339 > #1 0x00000000004f8608 in ndb_back_add () > #2 0x000000000043ce34 in fe_op_add () > #3 0x000000000043d695 in do_add () > #4 0x0000000000435dd9 in ?? () > #5 0x000000000043662d in ?? () > #6 0x00007fa1b0f43538 in ldap_int_thread_pool_wrapper (xpool=<value > optimized out>) at tpool.c:685 > #7 0x00007fa1af7729ca in start_thread () from /lib/libpthread.so.0 > #8 0x00007fa1ae27a70d in clone () from /lib/libc.so.6 > #9 0x0000000000000000 in ?? () > >> As always, when you get a core dump, post the gdb backtrace of the dump. Use >> the most recent release version, and make sure you use a non-optimized debug >> build with all debug symbols intact. All of these instructions are written on >> the page where you submit new Issues. >> > > > -- -- 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#6820) void functions with return's
by masarati＠aero.polimi.it 01 Feb '11

01 Feb '11

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: irrelevant > URL: > Submission from: (NULL) (128.6.31.135) > > > ITS # 6814 patch has a couple void functions with returns; that's not legal. > Patch below. > > I also note that it looks like some functions are missing prototypes in RE24. > That's only a warning to most compilers, but it might be nice to address that > too. > > --- servers/slapd/filter.c~ 2011-02-01 11:34:06.062872000 -0500 > +++ servers/slapd/filter.c 2011-02-01 11:34:16.721012000 -0500 > @@ -586,7 +586,7 @@ > void > filter2bv_x( Operation *op, Filter *f, struct berval *fstr ) > { > - return filter2bv_undef_x( op, f, 0, fstr ); > + filter2bv_undef_x( op, f, 0, fstr ); > } > > void > @@ -848,7 +848,7 @@ > void > filter2bv( Filter *f, struct berval *fstr ) > { > - return filter2bv_undef( f, 0, fstr ); > + filter2bv_undef( f, 0, fstr ); > } My fault, sorry. Thanks, p.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2011