(ITS#6901) openldap crash
by m.sheldyakov＠hostcomm.ru
Full_Name: Michail Sheldyakov
Version: 2.4.25
OS: FreeBSD 8.1-RELEASE-p1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (91.189.112.7)
Modify with ldapvi:
dn: cn=ovz678.hc.ru,ou=ovz,ou=hosts,ou=hosting,ou=sites,o=hc
changetype: add
macAddress:
hostType: main
cn: ovz678.hc.ru
objectClass: device
objectClass: ipHost
objectClass: intraExtra
objectClass: intraHost
objectClass: ieee802Device
description: ovz678.hc.ru
ipHostNumber: 127.0.0.1
unique overlay
olcUniqueURI: ldap:///ou=sites,o=hc?macAddress?sub?(&(objectClass=ipHost)(|(hostType=main)(hostType=xen)(hostType=service)))
openldap crash with core dump.
11 years, 11 months
(ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz
Full_Name: Daniel Pluta
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110410.patch
Submission from: (NULL) (2001:4ca0:0:fe11::1)
Hi,
I'm not quite sure whether the below described scenario can be successfully
avoided eg. using current slapd in combination with some kind of tricky ACL
configuration statements (if so, any advice is strongly appreciated).
Nevertheless, attached below you'll find a small patch that implements a
slightly enhanced (aka more restictive!) dnattr acl processing in case of
ACL_WDEL operations: In case the currently authenticated user tries to delete
his bindDN from the attribute referenced by the dnattr= acl statement, access is
denied.
Example scenario based on the following (nearly) minimal standard ACL
configuration:
access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children
by users =w
by * none
access to dn.onelevel="ou=groups,dc=foo,dc=bar"
by dnattr=owner write
by * none
access to dn.subtree="dc=foo,dc=bar"
by users read
by * none
... at first a user (user1) successfully creates (add) a new group entry,
where/because user1's DN is contained within the entry's owner attribute:
OPTS="-Z -D 'uid=user1,ou=users,dc=foo,dc=bar' -w 'user1'"
cat <<EOF | ldapadd ${OPTS}
dn: cn=test,ou=groups,dc=foo,dc=bar
objectClass: groupOfNames
objectClass: top
cn: test
member: cn=otheruser,ou=users,dc=foo,dc=bar
description: test group entry
owner: uid=user1,ou=users,dc=foo,dc=bar
EOF
Then, user1 (by mistake but) successfully modifies the just before created and
personaly owned entry, deleting his DN from the owner attribute:
cat <<EOF | ldapmodify ${OPTS}
dn: cn=test,ou=groups,dc=foo,dc=bar
changetype: modify
delete: owner
owner: uid=user1,ou=users,dc=foo,dc=bar
EOF
As a sideeffect from this second operation user1 has no chance to revert his
mistake because he has lost the previous assigned access rights to access this
entry by write. In fact nobody else (other than the rootdn) has a chance to
correct/delete the dangline group entry.
Another disabdvantage of the current implementation is the possibility to move
currently managed/owned entries (e.g. users or groups) to other owners/managers
without their notice/interaction.
The attached patch only interact in case of value delete operations. Thus, based
on the patch other owners/managers can be added/deleted as usual (except the DN
of the modifyer himself). Added owners/managers can take solely responsibility
of an entry by deleting all other owners/managers.
I would be very happy in case this patch or at least the based idea could find a
way into slapd's code. I don't mind whether this feature is implemented as an
extension of current dnattr processing (backward compatibility?) or as an
additional configuration option, e.g. "strictdnattr=..." (update
documentation?). Also I'm not sure whether set acl statements should or need to
be extended into this direction, too...
Thank you very much and best regards
Daniel
11 years, 11 months
RE: (ITS#6898)
by quanah＠zimbra.com
--On Saturday, April 09, 2011 7:56 PM +0000 quanah(a)zimbra.com wrote:
> --On Friday, April 08, 2011 9:25 PM -0400 Tyler Gates
> <tgates81(a)gmail.com> wrote:
>
>> I can confirm this is happening too, since 2.4.24. It was working in
>> 2.4.21, not sure about anything in between.
>
>> From the debian list:
>
> I've checked it with gdb too, and it locks at
> libraries/libldap/options.c:455
> That is in the function ldap_set_option, still no clue why it is locking
> there.
Full backtrace:
(gdb) thr apply all bt
Thread 1 (Thread 0x7f34820c4700 (LWP 26379)):
#0 0x00007f34803d6464 in __lll_lock_wait () from /lib/libpthread.so.0
#1 0x00007f34803d15d9 in _L_lock_953 () from /lib/libpthread.so.0
#2 0x00007f34803d13fb in pthread_mutex_lock () from /lib/libpthread.so.0
#3 0x00007f3481c62ff5 in ldap_pvt_thread_mutex_lock (mutex=0x1cac2a0) at
thr_posix.c:296
#4 0x00007f3481c87fb9 in ldap_set_option (ld=0x1cab030, option=17,
invalue=0x6164a8) at options.c:455
#5 0x000000000040ad83 in tool_conn_setup (dont=0, private_setup=0x405367
<private_conn_setup>) at common.c:1347
#6 0x00000000004059c7 in main (argc=8, argv=0x7fff16202148) at
ldapsearch.c:906
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 11 months
RE: (ITS#6898)
by quanah＠zimbra.com
--On Friday, April 08, 2011 9:25 PM -0400 Tyler Gates <tgates81(a)gmail.com>
wrote:
> I can confirm this is happening too, since 2.4.24. It was working in
> 2.4.21, not sure about anything in between.
>From the debian list:
I've checked it with gdb too, and it locks at
libraries/libldap/options.c:455
That is in the function ldap_set_option, still no clue why it is locking
there.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
11 years, 11 months
RE: (ITS#6898)
by tgates81＠gmail.com
I can confirm this is happening too, since 2.4.24. It was working in
2.4.21, not sure about anything in between.
11 years, 11 months
(ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by michael＠stroeder.com
Full_Name: Michael Ströder
Version: 2.4.25
OS:
URL:
Submission from: (NULL) (84.163.53.138)
The very same client code was successfully tested with OpenDJ 2.4.1 but does not
work with OpenLDAP 2.4.25.
See analysis by pyasn1 developer on the pyasn1 mailing list:
--------------------------------- snip ---------------------------------
It looks to me that your BER data does not fully match ASN.1 specification for
the SearchResultEntry object. According to RFC2251, the grammar is as follows:
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
...
Notice the [implicitly] tagged outer SEQUENCE. In your BER data, that additional
tag seems to be missing and default tag for SEQUENCE type is
used instead.
If you modify the original pyasn1 grammar for SearchResultEntry object to match
your BER data (but not the standard!), pyasn1 decoder succeeds.
>>> from pyasn1_modules.rfc2251 import SearchResultEntry
>>> from pyasn1.type.univ import Sequence
>>> from pyasn1.codec.ber import decoder
>>> ber = '0c\x043cn=Samba Unix UID
Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005'
>>> SearchResultEntry.tagSet
TagSet(Tag(tagClass=64, tagFormat=32, tagId=4))
# the following statement will invalidate SearchResultEntry grammar!
>>> SearchResultEntry.tagSet = univ.Sequence.tagSet
>>> SearchResultEntry.tagSet
TagSet(Tag(tagClass=0, tagFormat=32, tagId=16))
>>> searchResultEntry, _ = decoder.decode(ber,asn1Spec=SearchResultEntry())
>>> print searchResultEntry.prettyPrint()
SearchResultEntry:
objectName='cn=Samba Unix UID Pool,ou=Testing,dc=stroeder,dc=de'
attributes=PartialAttributeList:
Sequence:
type='uidNumber'
vals=SetOf:
'10005'
Sequence:
type='gidNumber'
vals=SetOf:
'10005'
>>>
Therefore my impression is that OpenLDAP yields incorrect BER data for
SearchResultEntry object. What do you think?
Cheers,
Ilya
> I'd like to decode a LDAPv3 control value returned by OpenLDAP 2.4.25 when
> Pre-Read-Control was sent along with a LDAP modify request. But decoding it
> does not work.
>
> Short example:
>
>>>> from pyasn1_modules.rfc2251 import SearchResultEntry
>>>> from pyasn1.codec.ber import decoder
>>>> ber = '0c\x043cn=Samba Unix UID
> Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005'
>>>> decoder.decode(ber,asn1Spec=SearchResultEntry())
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File
> "/usr/local/lib/python2.6/site-packages/pyasn1-0.0.13a-py2.6.egg/pyasn1/codec/ber/decoder.py",
> line 663, in __call__
> '%s not in asn1Spec: %s' % (tagSet, repr(asn1Spec))
> pyasn1.error.PyAsn1Error: TagSet(Tag(tagClass=0, tagFormat=32, tagId=16)) not
> in asn1Spec: SearchResultEntry()
>>>>
11 years, 11 months
Re: (ITS#6892) Segfault in Syncprov overlay
by ghola＠rebelbase.com
--000e0cd3f872854fb804a05e0ce0
Content-Type: text/plain; charset=ISO-8859-1
More information; This server is both a producer and a consumer.
Here are the logs preceeding the crash:
Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1007 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1005 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1004 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1003 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1002 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp:
cookie=rid=001,csn=20110408005040.759389Z#000000#000#000000
Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1001 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr 8 00:50:40 test-ldap01 slapd[8732]: slap_graduate_commit_csn: removing
0x20494b70 20110408005040.759389Z#000000#000#000000
Apr 8 00:50:40 test-ldap01 slapd[8732]: conn=1000 op=1 ENTRY
dn="widget=ldap02,ou=widgets,dc=domain,dc=net"
Apr 8 00:50:40 test-ldap01 slapd[8732]: syncrepl_entry: rid=001 be_modify
widget=ldap02,ou=widgets,dc=domain,dc=net (0)
Apr 8 00:50:40 test-ldap01 slapd[8732]: slap_queue_csn: queing 0x2055d810
20110408005040.759389Z#000000#000#000000
--000e0cd3f872854fb804a05e0ce0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
More information; This server is both a producer and a consumer.<br><br>Her=
e are the logs preceeding the crash:<br><br>Apr=A0 8 00:50:40 test-ldap01 s=
lapd[8732]: syncprov_sendresp: cookie=3Drid=3D001,csn=3D20110408005040.7593=
89Z#000000#000#000000<br>
Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid=
=3D001,csn=3D20110408005040.759389Z#000000#000#000000<br>Apr=A0 8 00:50:40 =
test-ldap01 slapd[8732]: conn=3D1007 op=3D1 ENTRY dn=3D"widget=3Dldap0=
2,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet"<br>
Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: conn=3D1005 op=3D1 ENTRY dn=3D&q=
uot;widget=3Dldap02,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet"<br>Apr=A0 8 00:=
50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid=3D001,csn=3D=
20110408005040.759389Z#000000#000#000000<br>
Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid=
=3D001,csn=3D20110408005040.759389Z#000000#000#000000<br>Apr=A0 8 00:50:40 =
test-ldap01 slapd[8732]: conn=3D1004 op=3D1 ENTRY dn=3D"widget=3Dldap0=
2,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet"<br>
Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: conn=3D1003 op=3D1 ENTRY dn=3D&q=
uot;widget=3Dldap02,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet"<br>Apr=A0 8 00:=
50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid=3D001,csn=3D=
20110408005040.759389Z#000000#000#000000<br>
Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: conn=3D1002 op=3D1 ENTRY dn=3D&q=
uot;widget=3Dldap02,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet"<br>Apr=A0 8 00:=
50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid=3D001,csn=3D=
20110408005040.759389Z#000000#000#000000<br>
Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: syncprov_sendresp: cookie=3Drid=
=3D001,csn=3D20110408005040.759389Z#000000#000#000000<br>Apr=A0 8 00:50:40 =
test-ldap01 slapd[8732]: conn=3D1001 op=3D1 ENTRY dn=3D"widget=3Dldap0=
2,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet"<br>
Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: slap_graduate_commit_csn: removi=
ng 0x20494b70 20110408005040.759389Z#000000#000#000000<br>Apr=A0 8 00:50:40=
test-ldap01 slapd[8732]: conn=3D1000 op=3D1 ENTRY dn=3D"widget=3Dldap=
02,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet"<br>
Apr=A0 8 00:50:40 test-ldap01 slapd[8732]: syncrepl_entry: rid=3D001 be_mod=
ify widget=3Dldap02,ou=3Dwidgets,dc=3Ddomain,dc=3Dnet (0)<br>Apr=A0 8 00:50=
:40 test-ldap01 slapd[8732]: slap_queue_csn: queing 0x2055d810 201104080050=
40.759389Z#000000#000#000000<br>
<br>
--000e0cd3f872854fb804a05e0ce0--
11 years, 11 months
Re: (ITS#6815) Feature Request: Accesslog filter
by marco.pizzoli＠gmail.com
--20cf300fb269cc453c04a055d2f8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I tried today to compile accesslog with this feature.
Probably I didn't follow the correct procedure, but I would prefer to ask
anyway to leave myself any doubt.
- I took the vanilla openldap-2.4.25 distribution
- unpacked the archive
- substituted the accesslog.c file with the corresponding one as available
in HEAD/MASTER
- compiled the software as if it were the 2.4.25 vanilla distribution
Now I obtain the following, at the startup:
[cut]
line 24 (logpurge 10+00:00 08:00)
line 28 (logsuccess FALSE)
line 30 (logbase all ou=3Dpeople,dc=3Dlancse,dc=3Dcsebo.it)
/opt/openldap2.4.25/libexec/slapd: symbol lookup error:
/opt/openldap2.4.25/libexec/openldap/accesslog-2.4.so.2: undefined symbol:
verbstring_to_mask
Could you help me?
Thanks in advance
Marco
On Wed, Feb 23, 2011 at 10:02 AM, Marco Pizzoli <marco.pizzoli(a)gmail.com>wr=
ote:
>
> On Wed, Feb 23, 2011 at 9:57 AM, Howard Chu <hyc(a)symas.com> wrote:
>
>> Marco Pizzoli wrote:
>>
>>> Hi Howard,
>>> thanks for this work.
>>>
>>> I noticed that you give me a baseDN under which I can have operations
>>> logged.
>>> If I would like to exclude one subtree from my principal tree, I need t=
o
>>> specify all the baseDN of other sibling-subtrees.
>>> To do this do I need to poli-invoke accesslog overlay?
>>>
>>
>> No, you can specify logbase multiple times in a single overlay.
>>
>
> Ok, thanks.
>
>
>
>> Possibly we can extend the directive to handle exclusion as well as
>> inclusion, to simplify this case.
>>
>
> This is effectively what I would need, in this case.
>
>
>
--=20
_________________________________________
Non =E8 forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
Jim Morrison
--20cf300fb269cc453c04a055d2f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I tried today to compile accesslog with this feature.<br>Probably I didn=
9;t follow the correct procedure, but I would prefer to ask anyway to leave=
myself any doubt.<br><br>- I took the vanilla openldap-2.4.25 distribution=
<br>
- unpacked the archive<br>- substituted the accesslog.c file with the corre=
sponding one as available in HEAD/MASTER<br>- compiled the software as if i=
t were the 2.4.25 vanilla distribution <br><br>Now I obtain the following, =
at the startup:<br>
<br>[cut]<br><span style=3D"font-family: courier new,monospace;">line 24 (l=
ogpurge 10+00:00 08:00)</span><br style=3D"font-family: courier new,monospa=
ce;"><span style=3D"font-family: courier new,monospace;">line 28 (logsucces=
s FALSE)</span><br style=3D"font-family: courier new,monospace;">
<span style=3D"font-family: courier new,monospace;">line 30 (logbase all ou=
=3Dpeople,dc=3Dlancse,dc=3D<a href=3D"http://csebo.it">csebo.it</a>)</span>=
<br style=3D"font-family: courier new,monospace;"><span style=3D"font-famil=
y: courier new,monospace;">/opt/openldap2.4.25/libexec/slapd: symbol lookup=
error: /opt/openldap2.4.25/libexec/openldap/accesslog-2.4.so.2: undefined =
symbol: verbstring_to_mask</span><br style=3D"font-family: courier new,mono=
space;">
<br>Could you help me?<br><br>Thanks in advance<br>Marco<br><br><br><div cl=
ass=3D"gmail_quote">On Wed, Feb 23, 2011 at 10:02 AM, Marco Pizzoli <span d=
ir=3D"ltr"><<a href=3D"mailto:marco.pizzoli@gmail.com">marco.pizzoli@gma=
il.com</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;"><br><div class=3D=
"gmail_quote"><div class=3D"im">On Wed, Feb 23, 2011 at 9:57 AM, Howard Chu=
<span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">h=
yc(a)symas.com</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>Marco Pizzoli 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;">
Hi Howard,<br>
thanks for this work.<br>
<br>
I noticed that you give me a baseDN under which I can have operations logge=
d.<br>
If I would like to exclude one subtree from my principal tree, I need to<br=
>
specify all the baseDN of other sibling-subtrees.<br>
To do this do I need to poli-invoke accesslog overlay?<br>
</blockquote>
<br></div>
No, you can specify logbase multiple times in a single overlay.<br></blockq=
uote></div><div><br>Ok, thanks.<br><br>=A0</div><div class=3D"im"><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1=
px solid rgb(204, 204, 204); padding-left: 1ex;">
Possibly we can extend the directive to handle exclusion as well as inclusi=
on, to simplify this case.<br></blockquote></div><div><br>This is effective=
ly what I would need, in this case.<br><br>
</div></div><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>_______________________=
__________________<br>Non =E8 forte chi non cade, ma chi cadendo ha la forz=
a di rialzarsi.<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jim Morrison<br>
--20cf300fb269cc453c04a055d2f8--
11 years, 11 months
