openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#4980) misaligned memory access (openssl?)
by hyc＠symas.com 23 May '07

23 May '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.35 > OS: Solaris 9 > URL: > Submission from: (NULL) (128.6.31.135) > > > OpenSSL 0.9.8e. slapd crashed with SIGBUS on Solaris/sparcv9, which almost > always means a misaligned memory access. Not sure if this is OpenLDAP's problem > or OpenSSL, but figured I'd at least track here (can always go bug the OpenSSL > guys if necessary)... This stack trace is pretty exclusively OpenSSL and libc code. Unless there's been a heap corruption somewhere, it appears to be an OpenSSL issue. -- -- 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

(ITS#4980) misaligned memory access (openssl?)
by richton＠nbcs.rutgers.edu 23 May '07

23 May '07

Full_Name: Aaron Richton Version: 2.3.35 OS: Solaris 9 URL: Submission from: (NULL) (128.6.31.135) OpenSSL 0.9.8e. slapd crashed with SIGBUS on Solaris/sparcv9, which almost always means a misaligned memory access. Not sure if this is OpenLDAP's problem or OpenSSL, but figured I'd at least track here (can always go bug the OpenSSL guys if necessary)... current thread: t@11 [1] t_delete(0x11c303480, 0x0, 0xffffffff7f268340, 0x2000, 0x2190, 0x1004e4290), at 0xffffffff7d24fab8 [2] _malloc_unlocked(0x80, 0x0, 0x0, 0x11ad552e0, 0x11ad552e0, 0x0), at 0xffffffff7d24f068 [3] malloc(0x80, 0xffffffff7e502458, 0xffffffff7e5014f0, 0xf68, 0x24fd00, 0xc00), at 0xffffffff7d24ee94 =>[4] CRYPTO_malloc(num = ???, file = ???, line = ???) (optimized), at 0xffffffff7e2b2274 (line ~304) in "mem.c" [5] bn_expand_internal(b = ???, words = ???) (optimized), at 0xffffffff7e308140 (line ~336) in "bn_lib.c" [6] BN_bin2bn(s = ???, len = ???, ret = ???) (optimized), at 0xffffffff7e308940 (line ~451) in "bn_lib.c" [7] RSA_eay_private_decrypt(flen = ???, from = ???, to = ???, rsa = ???, padding = ???) (optimized), at 0xffffffff7e32f160 (line ~517) in "rsa_eay.c" [8] ssl3_get_client_key_exchange(s = ???) (optimized), at 0xffffffff7e625150 (line ~1732) in "s3_srvr.c" [9] ssl3_accept(s = ???) (optimized), at 0xffffffff7e6227d0 (line ~449) in "s3_srvr.c" [10] ldap_pvt_tls_accept(sb = 0x11be3ac90, ctx_arg = 0x1004e4290), line 866 in "tls.c" [11] connection_read(s = 189), line 1348 in "connection.c" [12] slapd_daemon_task(ptr = (nil)), line 2359 in "daemon.c"

1 0

Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by nvoutsin＠noc.uoa.gr 23 May '07

23 May '07

Here is a simplified configuration that can be used to replicate the problem. I understand that such an error can not be easily triggered and in that sense might be considered as a low priority issue, but then again I believe it is worth mentioning. (I hope, I am not missing anything here...) # #include schemas here # access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by * none argsfile /var/openldap/run/slapd.args pidfile /var/openldap/run/slapd.pid loglevel any modulepath /opt/OpenLdap/sbin moduleload back_bdb.la moduleload back_relay.la moduleload rwm.la backend bdb database bdb suffix "dc=foo,dc=bar" rootdn "uid=manager,dc=foo,dc=bar" rootpw "secret" directory /var/openldap/bdb access to * by * read database relay suffix "" relay "dc=foo,dc=bar" massage access to * by * read As you can see from the logs below, ops like this one: SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)" SRCH attr=hasSubordinates objectClass fail, because slapd looks for an non-existent entry such as bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar"). The logs: ========= daemon: read activity on 11 connection_get(11) connection_get(11): got connid=0 connection_read(11): checking for input on id=0 daemon: select: listen=7 active_threads=0 tvp=NULL do_search >>> dnPrettyNormal: <dc=foo,dc=bar> <<< dnPrettyNormal: <dc=foo,dc=bar>, <dc=foo,dc=bar> SRCH "dc=foo,dc=bar" 1 0 0 0 0 begin get_filter PRESENT end get_filter 0 filter: (objectClass=*) => get_ctrls => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) <= get_ctrls: n=1 rc=0 err="" attrs: hasSubordinates objectClass conn=0 op=5 SRCH base="dc=foo,dc=bar" scope=1 deref=0 filter="(objectClass=*)" conn=0 op=5 SRCH attr=hasSubordinates objectClass slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 ==> limits_get: conn=0 op=5 dn="uid=manager,dc=foo,dc=bar" [rw] searchDN: "dc=foo,dc=bar" -> "dc=foo,dc=bar,dc=foo,dc=bar" >>> dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar> <<< dnPrettyNormal: <dc=foo,dc=bar,dc=foo,dc=bar>, <dc=foo,dc=bar,dc=foo,dc=bar> str2filter "(objectClass=*)" begin get_filter PRESENT end get_filter 0 => bdb_search bdb_dn2entry("dc=foo,dc=bar,dc=foo,dc=bar") => bdb_dn2id("dc=bar,dc=foo,dc=bar") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=0 op=5 p=3 send_ldap_result: err=10 matched="dc=foo,dc=bar" text="" [rw] matchedDN: "dc=foo,dc=bar" -> "" >>> dnPretty: <> <<< dnPretty: <> send_ldap_response: msgid=6 tag=101 err=32 conn=0 op=5 SEARCH RESULT tag=101 err=32 nentries=0 text= Nikos Pierangelo Masarati wrote: > nvoutsin(a)noc.uoa.gr wrote: >> While slapd does not segfault anymore, slapd insists to concatenate >> unrelated database suffixes during search operations that look for attrs >> such as hasSubordinates. >> >> I mention this here because it seems to be related somehow > > As I could see it working as expected (by me, at least), I suggest you > cook a very simple example, consisting in two slapd.conf (one for the > remote server, and one for the offending mixed local-proxy-relay setup), > and as many data in LDIF format and submit it, so that you can show what > you consider an incorrect behavior. Otherwise, I don't see any further > indication of a bug. > > 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

Re: (ITS#4976) memory corruption in test008-concurrency
by h.b.furuseth＠usit.uio.no 22 May '07

22 May '07

hyc(a)symas.com writes: > Try using ElectricFence, with my pthread patches. Still refuses to crash... -- Regards, Hallvard

1 0

Re: (ITS#4979) Bad response when requesting bad attributes
by hyc＠symas.com 22 May '07

22 May '07

Emmanuel Lecharny wrote: > Howard Chu a écrit : >> This works as designed - requesting an objectclass means to request >> all of the attributes included in that objectclass. In current >> revisions we expect objectClass names to be prefixed with "@" but the >> original behavior is still supported for backward compatibility. >> > Oh... Is there any RFC which expose this intended behaviour ? RFC 4529. This ITS will be closed. -- -- 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#4979) Bad response when requesting bad attributes
by hyc＠symas.com 22 May '07

22 May '07

elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.3.32 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.236.207.89) > > > When searching for entries using attributes to filter the result, you get all > the entries attributes if you give a wrong attribute : > > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" 9.9.9 > > will correctly returns only the DNs of all found entries, as if the 9.9.9 > attribute was 1.1 > > but > > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" person > > will return all entries attributes, as if the 'person' was substituted by "*" > > Of course, 'person' is not an attribute, but an objectClass, but the user intent > was to get only one single attribute value, so I don't think that returning > everything is correct. > > This is obviously not a serious issue. This works as designed - requesting an objectclass means to request all of the attributes included in that objectclass. In current revisions we expect objectClass names to be prefixed with "@" but the original behavior is still supported for backward compatibility. -- -- 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#4979) Bad response when requesting bad attributes
by elecharny＠apache.org 22 May '07

22 May '07

Hallvard B Furuseth a écrit : >elecharny(a)apache.org writes: > > >>ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b >>"dc=example,dc=com" -s sub "(objectClass=*)" person >> >>will return all entries attributes, as if the 'person' was substituted >>by "*" >> >> > >That is what RFC 4511 says. Section 4.5.1.8 (SearchRequest.attributes): > "If an attribute description in the list is not recognized, it is > ignored by the server." >Ignoring "person" yields an empty list, which works like a "*". > >I'm guessing that's not what it was intended to say though. RFC 1777 >(LDAPv2) did not have it, so 'person' would work like '1.1' does now. > > > Well, RFC 4511 just states that if the attribute is unknow, then it is ignored, but say nothing about using '1.1' or '*' . Ignoring the only attributes given by the user and substitute a '*' to it is a violation of user intent, IMHO (even if this user was wrong when selecting the attribute). RFC 4511 authors didn't thought of such a case, I guess ;) Anyway, OpenLdap behave differently if the attribute is unknown (9.9.9) and when it is known by the server (at least, the OID is known, even if it's not an attribute object), when it should returns always the same result : either '*' or '1.1'. This is not the case, and it's not consistent, whatever RFC 4511 says - or omits to say :) -. Emmanuel

1 0

Re: (ITS#4979) Bad response when requesting bad attributes
by h.b.furuseth＠usit.uio.no 22 May '07

22 May '07

elecharny(a)apache.org writes: > ldapsearch -h localhost -p 10389 -D "uid=Admin,ou=system" -w secret -b > "dc=example,dc=com" -s sub "(objectClass=*)" person > > will return all entries attributes, as if the 'person' was substituted > by "*" That is what RFC 4511 says. Section 4.5.1.8 (SearchRequest.attributes): "If an attribute description in the list is not recognized, it is ignored by the server." Ignoring "person" yields an empty list, which works like a "*". I'm guessing that's not what it was intended to say though. RFC 1777 (LDAPv2) did not have it, so 'person' would work like '1.1' does now. -- Regards, Hallvard

1 0

Re: (ITS#4978) slapo-ppolicy.5 and missing Zero value example
by ghenry＠suretecsystems.com 22 May '07

22 May '07

<quote who="hyc(a)symas.com"> > ahasenack(a)terra.com.br wrote: >> On Mon, May 21, 2007 at 09:25:23PM +0000, ghenry(a)OpenLDAP.org wrote: >>> draft-behera-ldap-password-policy-xx.txt and ppolicy.schema list: >>> >>> "A 000001010000Z value means that the account has been locked >>> permanently, and >>> that only a password administrator can unlock the account." >>> >>> But pwdAccountLockedTime doesn't use integerMatch, so an example of the >>> above >>> syntax is needed with anything that has a generalizedTimeMatch. I think >>> pwdAccountLockedTime is the only one? >> >> The slapo-ppolicy(5) manpage is actually misleading. It implies that >> the value is a plain zero, which doesn't work: >> "If pwdAccountLockedTime is set to zero (0), the user's account (...)" > > That text in the manpage came from an earlier revision of the ppolicy > draft; it just wasn't updated when the meaning was clarified in a later > draft version. Looks like Gavin has fixed it in HEAD now. Yes, sorry. I thought silence meant it was ok to go ahead. This is my first ever commit, so I'll be a bit more patient next time ;-) Thanks. > > -- > -- 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#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by ando＠sys-net.it 22 May '07

22 May '07

nvoutsin(a)noc.uoa.gr wrote: > While slapd does not segfault anymore, slapd insists to concatenate > unrelated database suffixes during search operations that look for attrs > such as hasSubordinates. > > I mention this here because it seems to be related somehow As I could see it working as expected (by me, at least), I suggest you cook a very simple example, consisting in two slapd.conf (one for the remote server, and one for the offending mixed local-proxy-relay setup), and as many data in LDIF format and submit it, so that you can show what you consider an incorrect behavior. Otherwise, I don't see any further indication of a bug. 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

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