Re: (ITS#4980) misaligned memory access (openssl?)
by hyc＠symas.com
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/
16 years, 4 months
(ITS#4980) misaligned memory access (openssl?)
by richton＠nbcs.rutgers.edu
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"
16 years, 4 months
Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by nvoutsin＠noc.uoa.gr
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
> ---------------------------------------
>
>
16 years, 4 months
Re: (ITS#4979) Bad response when requesting bad attributes
by hyc＠symas.com
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/
16 years, 4 months
Re: (ITS#4979) Bad response when requesting bad attributes
by elecharny＠apache.org
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
16 years, 4 months
Re: (ITS#4979) Bad response when requesting bad attributes
by h.b.furuseth＠usit.uio.no
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
16 years, 4 months
Re: (ITS#4978) slapo-ppolicy.5 and missing Zero value example
by ghenry＠suretecsystems.com
<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/
>
>
>
16 years, 4 months
Re: (ITS#4958) slapd segfaults when overlay rwm, suffixmassage is used in conjunction with empty suffix
by ando＠sys-net.it
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
---------------------------------------
16 years, 4 months
