openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6903) BerkeleyDB
by h.b.furuseth＠usit.uio.no 12 Apr '11

12 Apr '11

matdave(a)yahoo.com writes: > New to openldap, downloaded latest stable version and tried to configure with > Berkeley 11g from Oracle. > Configure message along the lines of 'Berkeley (default) no' > 'Berkeley not enabld/installed' See README, "REQUIRED SOFTWARE": SLAPD: BDB and HDB backends require Oracle Berkeley DB 4.4, 4.5, 4.6, 4.7, or 4.8. It is highly recommended to apply the patches from Oracle for a given release. Closing this ITS. And please use openldap-technical(a)openldap.org for help requests. ITS is for bug reports and contributions. -- Hallvard

1 0

(ITS#6903) BerkeleyDB
by matdave＠yahoo.com 11 Apr '11

11 Apr '11

Full_Name: Terry Bennett Version: 2.4.23 OS: RHEL 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.17.5.3) New to openldap, downloaded latest stable version and tried to configure with Berkeley 11g from Oracle. Configure message along the lines of 'Berkeley (default) no' 'Berkeley not enabld/installed' (Sorry at work no access to actual message) General email search suggested LD_LIBRARY_PATH, CPPFLAGS etc - tried no success. Is there a compatability issue between these too versions. Regards Terry Bennett

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 11 Apr '11

11 Apr '11

A small but important bugfix for my patch, that also honors access "to all values", can be found here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-20110412.patch

1 0

Re: (ITS#6902) test008-concurrency failed on test
by vorgusa＠earthlink.net 11 Apr '11

11 Apr '11

ahhh you are right. Tests finished without any problem. Guess my VM was too minimal. Thanks for the help On 04/11/2011 01:42 PM, Quanah Gibson-Mount wrote: > --On Monday, April 11, 2011 5:05 PM +0000 vorgusa(a)earthlink.net wrote: > > >> ./scripts/test008-concurrency: 62: time: not found > > I suggest you install the "time" command. > > --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 >

1 0

RE: (ITS#6891)
by quanah＠zimbra.com 11 Apr '11

11 Apr '11

--On Monday, April 11, 2011 3:32 PM +0000 tgates81(a)gmail.com wrote: > Can someone confirm whether or not this is a bug or just a > misconfiguration error on my part? I am at a complete loss. > None of what you provided as output from gdb was output from gdb. Get a valid backtrace. --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

1 0

Re: (ITS#6902) test008-concurrency failed on test
by quanah＠zimbra.com 11 Apr '11

11 Apr '11

--On Monday, April 11, 2011 5:05 PM +0000 vorgusa(a)earthlink.net wrote: > ./scripts/test008-concurrency: 62: time: not found I suggest you install the "time" command. --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

1 0

(ITS#6902) test008-concurrency failed on test
by vorgusa＠earthlink.net 11 Apr '11

11 Apr '11

Full_Name: Chris Version: 2.4.25 OS: Ubuntu Server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.47.84.194) after running make test I received the below errors. I have my configuration options below and the configuration passed Configuration options ./configure --enable-sql --enable-ldap --enable-ppolicy MAKE TEST >>>>> Starting test008-concurrency for bdb... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... MONITORDB yes SRCDIR ./testdata DSTDIR /opt/openldap-2.4.25/tests/testrun pwd /opt/openldap-2.4.25/tests Using tester for concurrent server access... ./scripts/test008-concurrency: 62: time: not found slapd-tester failed (127)! >>>>> ./scripts/test008-concurrency failed for bdb (exit 127) make[2]: *** [bdb-yes] Error 127 make[2]: Leaving directory `/opt/openldap-2.4.25/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/opt/openldap-2.4.25/tests' make: *** [test] Error 2

1 0

RE: (ITS#6891)
by tgates81＠gmail.com 11 Apr '11

11 Apr '11

Can someone confirm whether or not this is a bug or just a misconfiguration error on my part? I am at a complete loss.

1 0

(ITS#6901) openldap crash
by m.sheldyakov＠hostcomm.ru 11 Apr '11

11 Apr '11

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.

1 0

(ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 10 Apr '11

10 Apr '11

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

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