openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#5343) cn=config crash when deleting attrs
by h.b.furuseth＠usit.uio.no 30 Jan '08

30 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.203.232) Submitted by: hallvard back-config crashes if I delete some attribute, even some which does not exist, and then olcAttributeOptions: bash$ cat slapd.conf include servers/slapd/schema/core.schema database config rootdn cn=config rootpw secret bash$ ldapmodify -xh:3890 -Dcn=config -wsecret dn: cn=config changetype: modify # or use "delete: o" delete: olcAllows - delete: olcAttributeOptions olcAttributeOptions: foo - Crash in bconfig.c:config_modify_internal line 4843 because d == NULL: 4842 if ( ml->sml_values ) { 4843 d = d->next; 4844 ch_free( dels ); 4845 dels = d; 4846 } Backtrace: #0 0x000000000042db19 in config_modify_internal (ce=0x9cb710, op=0x9d7330, rs=0x41801cb0, ca=0x417ff750) at bconfig.c:4843 #1 0x000000000042e34a in config_back_modify (op=0x9d7330, rs=0x41801cb0) at bconfig.c:4991 #2 0x0000000000461107 in fe_op_modify (op=0x9d7330, rs=0x41801cb0) at modify.c:300 #3 0x00000000004609b0 in do_modify (op=0x9d7330, rs=0x41801cb0) at modify.c:175 #4 0x0000000000440dd8 in connection_operation (ctx=0x41801e00, arg_v=0x9d7330) at connection.c:1087 #5 0x0000000000441306 in connection_read_thread (ctx=0x41801e00, argv=0x9) at connection.c:1214 #6 0x00002b100d4c354f in ldap_int_thread_pool_wrapper (xpool=0x927a10) at tpool.c:625 #7 0x00002b100e1e6317 in start_thread () from /lib/libpthread.so.0 #8 0x00002b100f935d5d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? () Also the error message from deleting just olcAttributeOptions is bad: bash$ ldapmodify -xh:3890 -Dcn=config -wsecret dn: cn=config changetype: modify replace: olcAttributeOptions olcAttributeOptions: foo ldap_modify: Internal (implementation specific) error (80) additional info: modify/delete: modifyTimestamp: no such attribute modifying entry "cn=config" Finally "replace:" only needs to fail if there are options to delete, not if one adds a line with just "attributeOptions" to slapd.conf. That removes the default, "lang-".

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by hyc＠symas.com 29 Jan '08

29 Jan '08

Aaron Richton wrote: > Backend is hdb. The add was done under 2.3.37, the server has since been > upgraded to 2.3.40 (last Thursday). > > db_dump -p does show a high character... > > \80\10cn=172.23.58.210\00cn=1\b72.23.58.210\00\00\00\00\00\00\01\e4e > > which I suppose you're theorizing is off-by-one on the disk. BTW, slapcat > doesn't agree with ldapsearch here, which might be construed as a bug? > (Although it's tough to call something a bug in an impossible situation, I > admit.) > I dunno. I suppose if the hardware is bad then I might be seeing all sorts > of crazy stuff. But we're talking modern sparc/solaris hardware: all my > other boxes are pretty good about screaming during their death. And they > also don't have the amazingly-coincidental upgrade to 2.3.40 from last > Thursday, either. (Which I started seeing err=80 returns within 24 hours > of, after not seeing them...well, almost ever in production.) It's all > just a bit too perfect a storm for my taste...but I'd obviously defer to > you when it comes to bdb internals. Well, if the entry was created a while ago and hasn't ever been modrdn'd then this DB record would never have been touched since then. (Or more to the point, not modrdn'd since the 2.3.40 upgrade.) It's possible that a software bug might have caused a stray bitwise OR to toggle that bit in an in-memory cached page, but seems unlikely that a page corrupted in that manner would have been written back to disk. Unless of course this record is one of the last ones in the DB before the upgrade, and new entries were added right after it. ("Last" is obviously imprecise. But the point is you would have had to have created some new entries after the upgrade whose DNs would cause their records to fall on the same DB page as this record, meaning they're close in the sort order and such.) > With that in mind, I might as well see through your theory. I'll play with > a second box tomorrow and see if I can reproduce fresh. And for most err=80 situations, there ought to be BerkeleyDB error messages in the log as well. -- -- Howard Chu Chief Architect, 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#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu 29 Jan '08

29 Jan '08

Backend is hdb. The add was done under 2.3.37, the server has since been upgraded to 2.3.40 (last Thursday). db_dump -p does show a high character... \80\10cn=172.23.58.210\00cn=1\b72.23.58.210\00\00\00\00\00\00\01\e4e which I suppose you're theorizing is off-by-one on the disk. BTW, slapcat doesn't agree with ldapsearch here, which might be construed as a bug? (Although it's tough to call something a bug in an impossible situation, I admit.) I dunno. I suppose if the hardware is bad then I might be seeing all sorts of crazy stuff. But we're talking modern sparc/solaris hardware: all my other boxes are pretty good about screaming during their death. And they also don't have the amazingly-coincidental upgrade to 2.3.40 from last Thursday, either. (Which I started seeing err=80 returns within 24 hours of, after not seeing them...well, almost ever in production.) It's all just a bit too perfect a storm for my taste...but I'd obviously defer to you when it comes to bdb internals. With that in mind, I might as well see through your theory. I'll play with a second box tomorrow and see if I can reproduce fresh.

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by hyc＠symas.com 29 Jan '08

29 Jan '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.40 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > $ ldapsearch -LLL '(cn=172.23.58.210)' > dn:: Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvd > T1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM= > objectClass: top > objectClass: dhcpHost > cn: 172.23.58.210 > dhcpStatements: fixed-address 172.23.58.210 > dhcpHWAddress: ethernet 00:17:3f:bf:c2:04 > > > Is it just me, or does my cn attribute not match the cn in the dn? Uhhh...now > what? > (and no, I wasn't using an editor on the bdb files, or whatever other conspiracy > theory is out there.) Also, if it helps, you can see on openldap-software my > other misadventures with 2.3.40...this is just one that's really easy to prove. You didn't mention what backend you're using. I'd examine the dn2id.bdb file (use db_dump -p) and see if this DN is corrupted there. Also, was this entry created using 2.3.40, or using an earlier version? Interesting that the byte differs from the expected value by a single bit (it has its high bit set). Personally I suspect the hardware is flaking out. -- -- Howard Chu Chief Architect, 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#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu 29 Jan '08

29 Jan '08

> does this help? the "7" in 172 is something else (octal 267, I believe). Precisely. How did that get in my database? It MUST match the dn per spec, right? And it doesn't. (The character almost certainly should be '7.' If I go back in my logs far enough, I'll bet I can even find an ADD log showing it as such...)

1 0

Re: (ITS#5342) DN and naming attribute mismatch
by ando＠sys-net.it 29 Jan '08

29 Jan '08

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.40 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > $ ldapsearch -LLL '(cn=172.23.58.210)' > dn:: Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvd > T1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM= > objectClass: top > objectClass: dhcpHost > cn: 172.23.58.210 > dhcpStatements: fixed-address 172.23.58.210 > dhcpHWAddress: ethernet 00:17:3f:bf:c2:04 > > > Is it just me, or does my cn attribute not match the cn in the dn? Uhhh...now > what? > (and no, I wasn't using an editor on the bdb files, or whatever other conspiracy > theory is out there.) Also, if it helps, you can see on openldap-software my > other misadventures with 2.3.40...this is just one that's really easy to prove. bash-3.00$ echo -n "Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvdT1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM=" | base64 -d | od -c 0000000 c n = 1 267 2 . 2 3 . 5 8 . 2 1 0 0000020 , c n = C l i e n t s , c n = R 0000040 e s N e t S e r v i c e C o 0000060 n f i g , o u = H o s t C o n 0000100 f i g , o = R u t g e r s C C 0000120 F , c = U S 0000126 does this help? the "7" in 172 is something else (octal 267, I believe). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5342) DN and naming attribute mismatch
by richton＠nbcs.rutgers.edu 29 Jan '08

29 Jan '08

Full_Name: Aaron Richton Version: 2.3.40 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) $ ldapsearch -LLL '(cn=172.23.58.210)' dn:: Y249MbcyLjIzLjU4LjIxMCxjbj1DbGllbnRzLGNuPVJlc05ldCBTZXJ2aWNlIENvbmZpZyxvd T1Ib3N0IENvbmZpZyxvPVJ1dGdlcnMgQ0NGLGM9VVM= objectClass: top objectClass: dhcpHost cn: 172.23.58.210 dhcpStatements: fixed-address 172.23.58.210 dhcpHWAddress: ethernet 00:17:3f:bf:c2:04 Is it just me, or does my cn attribute not match the cn in the dn? Uhhh...now what? (and no, I wasn't using an editor on the bdb files, or whatever other conspiracy theory is out there.) Also, if it helps, you can see on openldap-software my other misadventures with 2.3.40...this is just one that's really easy to prove.

1 0

Re: (ITS#5341) Invalid TLSCipherSuite causes hang
by vorlon＠debian.org 29 Jan '08

29 Jan '08

On Tue, Jan 29, 2008 at 11:31:43AM -0800, Quanah Gibson-Mount wrote: > --On Tuesday, January 29, 2008 11:09 AM -0800 Steve Langasek > <vorlon(a)debian.org> wrote: > > Anyway, the documented syntax for TLSCipherSuite is "$cipher1:$cipher2", > > not "$cipher1 $cipher2"; but setting such values gives me a hang on > > startup (which should be investigated). > Filed upstream: > <http://www.OpenLDAP.org/its/index.cgi?findid=5341> Sorry, the description of this ITS is inverted. It's *valid* ciphersuite values (i.e., "cipher1:cipher2") that cause the hang; invalid space-separated values are merely truncated after the first cipher in the list, which doesn't cause a hang, it just prevents the cipher list from being useful. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

1 0

(ITS#5341) Invalid TLSCipherSuite causes hang
by quanah＠OpenLDAP.org 29 Jan '08

29 Jan '08

Full_Name: Quanah Gibson-Mount Version: 2.4.7 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) Setting TLSCipherSuite to "cipher1 cipher2" rather than "cipher1:cipher2" causes slapd to hang on startup (at least when using GnuTLS). It appears to be hanging indefinitely in ldap_pvt_tls_set_option() --Quanah

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 29 Jan '08

29 Jan '08

Other bugs: * be->be_chk_referrals: back-bdb and back-ldif can send errors from be->be_chk_referrals. As far as I can tell that is wrong: It should return an LDAP result code, but only send it if it is LDAP_REFERRAL. backend_check_referrals() will send other errors, and success means it'll proceed to the be->be_<operation>() call. * be->be_fetch() (bi->bi_entry_get_rw()): The LDAP result code matters to at least aci.c:dynacl_aci_mask() and frontendDB->be_compare() (compare.c:fe_op_compare()). These use it via backend_attribute(), using frontendDB->be_attribute() (fe_acl_attribute()), using backend.c:be_entry_get_rw(). It can return just a boolean in back-null, back-ldif, back-relay and back-config. back-null usually pretends the entries are present, so maybe it should do "return oc ? LDAP_NO_SUCH_ATTRIBUTE : LDAP_BUSY;". * Internal slapd errors. back-ldap:ldap_back_entry_get() can return LDAP_NO_MEMORY. Maybe that's OK and instead send_ldap_response() should change negative negative result codes to LDAP_OTHER? -- Hallvard

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