openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

ITS#6480
by masarati＠aero.polimi.it 22 Feb '10

22 Feb '10

Your analysis looks correct, but the solution is not: - If the server does not recognize the control type, determines that it is not appropriate for the operation, or is otherwise unwilling to perform the operation with the control, and if the criticality field is FALSE, the server MUST ignore the control. Your fix may result in not ignoring the control. A fix is coming. Thanks, p.

1 0

(ITS#6480) Incorrect handling of noncritical LDAP_CONTROL_X_SEARCH_OPTIONS
by alastair.mccormack＠ioko.com 22 Feb '10

22 Feb '10

Full_Name: Alastair McCormack Version: 2.3.43 OS: Red Hat Enterprise Linux Server release 5.4 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.98.0.249) Proprietary LDAP Client ---LDAPv3---> OpenLDAP 2.3.43 Query: ??sub(objectClass=*) Client Receives Error 53: "searchOptions contained unrecognized flag" This works fine when client is pointed at a Windows AD Domain Controller. Tracing reveals that client is setting: Control: oid=1.2.840.113556.1.4.1340 = SERVER_SEARCH_FLAG_PHANTOM_ROOT noncritical By my novice understanding of the LDAP v3 RFC, the non-critical flag should mean that the search should not fail if the Control is not supported. However, it would seem that in controls.c an unknown or unimplemented flag is causing an exception even if the Control option is non critical. I have worked around this by creating and applying the following patch (includes typo fix): --- /var/tmp/controls.c-ignore-non-crit-search-flags 2010-02-22 15:16:16.000000000 +0000 +++ openldap-2.3.43/servers/slapd/controls.c 2008-04-09 02:12:47.000000000 +0100 @@ -1425,10 +1425,10 @@ static int parseSearchOptions ( : SLAP_CONTROL_NONCRITICAL; } - if ( search_flags & ~(LDAP_SEARCH_FLAG_DOMAIN_SCOPE) ) { + if ( (search_flags & ~(LDAP_SEARCH_FLAG_DOMAIN_SCOPE)) && ctrl->ldctl_iscritical ) { /* Other search flags not recognised so far, * including: - * LDAP_SEARCH_FLAG_PHANTOM_ROOM + * LDAP_SEARCH_FLAG_PHANTOM_ROOT */ rs->sr_text = "searchOptions contained unrecognized flag"; return LDAP_UNWILLING_TO_PERFORM; I have very little C knowledge so this was more of a POC rather than a suggested solution. Many thanks for a superb application. Keep up the good work :) Alastair McCormack

1 0

Re: (ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de 22 Feb '10

22 Feb '10

That's it, Thank you. hellweiss > You need to add (before "olcAccess: {3}") something that allows search > access to any valid search base. OpenLDAP 2.4 requires search access to > the entry pseudo-attribute of the search base. > > Something like > > olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=entry by * read > > p. > -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

1 0

ITS#6475
by masarati＠aero.polimi.it 21 Feb '10

21 Feb '10

The "easy" fix is here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-21-dontusecopy-…> I haven't committed it (needs some polishing) because it touches slapo-chain(5) in a couple of places, and I'd rather be sure it does not break anything. I won't be able to work at it for a while. It needs some polishing (SASL attributes that may need dontUseCopy should be at least configurable and so). Please test.

1 0

Re: (ITS#6479) olcAccess filter does not work
by masarati＠aero.polimi.it 20 Feb '10

20 Feb '10

You need to add (before "olcAccess: {3}") something that allows search access to any valid search base. OpenLDAP 2.4 requires search access to the entry pseudo-attribute of the search base. Something like olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=entry by * read p.

1 0

Re: (ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de 20 Feb '10

20 Feb '10

> > > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=*) > > attrs=cn,email,entry,objectClass,uid by * read > > > > works ok, changing the olcAccess filter to e.g. person > > > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=person) > > attrs=cn,email,entry,objectClass,uid by * read > > > > gives no results > > Given that this is specifically tested by test006, and this test routinely > passes, and considering how incomplete your report is, I recommend you > provide a means to easily reproduce the issue (e.g. detailed slapd.conf, > LDIF data and details about the unsuccessful operation) in order to have > this issue report processed further. > > p. Hello p., so, if I got you right, this 'test006' states, that this must be a configuration error and I better move on to the support Mailinglist or somewhere else. If this should not be the case, here's what i've got: There's no slapd.conf, it's empty # {1}hdb, config dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=site olcRootDN: cn=admin,dc=site olcRootPW: xxxxxxxxxxxxxxxx olcDbCacheSize: 10000 olcDbCheckpoint: 1024 5 olcDbIDLcacheSize: 30000 olcDbIndex: objectclass eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: member eq olcDbIndex: memberUid eq olcDbIndex: mail eq olcDbIndex: cn eq,sub olcDbIndex: displayName eq,sub olcDbIndex: uid eq,sub olcDbIndex: sn eq,sub olcDbIndex: givenName eq,sub olcAccess: {0}to attrs=userPassword by self write by * auth olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to attrs=userPKCS12 by self read by * none olcAccess: {3}to dn.subtree="dc=site" filter=(objectclass=inetOrgPerson) attrs =cn,email,entry,objectClass,uid by * read olcAccess: {4}to * by * none I've only access to the test system now, so the dc and objectclass is different. Here is the only user: # test, people, site dn: uid=test,ou=people,dc=site cn: test test gidNumber: 100 givenName: test homeDirectory: /home/test loginShell: /bin/bash objectClass: top objectClass: posixAccount objectClass: inetOrgPerson sn: test uid: test uidNumber: 1001 If I do an ldapsearch -x -b ou=people,dc=site or as test User there are no results. What I want to achieve is Anonymous and User read access only to inetOrgPerson Entries and special attributes, nothing else. No groupOfNames or device Entries in the subtree. Regards Hellweiss -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

1 0

Re: (ITS#6479) olcAccess filter does not work
by masarati＠aero.polimi.it 19 Feb '10

19 Feb '10

> Full_Name: hellweiss > Version: 2.4.20 > OS: openSuSE > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.135.6.106) > > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=*) > attrs=cn,email,entry,objectClass,uid by * read > > works ok, changing the olcAccess filter to e.g. person > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=person) > attrs=cn,email,entry,objectClass,uid by * read > > gives no results Given that this is specifically tested by test006, and this test routinely passes, and considering how incomplete your report is, I recommend you provide a means to easily reproduce the issue (e.g. detailed slapd.conf, LDIF data and details about the unsuccessful operation) in order to have this issue report processed further. p.

1 0

(ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de 19 Feb '10

19 Feb '10

Full_Name: hellweiss Version: 2.4.20 OS: openSuSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.135.6.106) olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=*) attrs=cn,email,entry,objectClass,uid by * read works ok, changing the olcAccess filter to e.g. person olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=person) attrs=cn,email,entry,objectClass,uid by * read gives no results

1 0

Re: (ITS#6478) slapd crashes with segfault
by quanah＠zimbra.com 19 Feb '10

19 Feb '10

--On Friday, February 19, 2010 2:18 PM +0000 wolfgang.hummel(a)hp.com wrote: > Full_Name: Wolfgang Hummel > Version: 2.4.21 > OS: RedHat Linux 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.203.233.80) Please provide a backtrace from a version of slapd compiled with full debugging symbols (CFLAGS="-g"). Your report is too vague to provide any help. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6478) slapd crashes with segfault
by masarati＠aero.polimi.it 19 Feb '10

19 Feb '10

wolfgang.hummel(a)hp.com wrote: > Full_Name: Wolfgang Hummel > Version: 2.4.21 > OS: RedHat Linux 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.203.233.80) > > > OpenLdap crashes occasionally with a segfault error, e.g. > [root@ts2mstsv010 Ldap]# dmesg|grep slapd > slapd[8783]: segfault at 00000000000000f0 rip 0000000000459b72 rsp > 000000004286e990 error 4 > [root@ts2mstsv010 Ldap]# > After the crash, stale lock files exist, slapd_db_recover has to be run > The server is HP D380 G5 with Intel Quadcore CPU @ 2 GHz > 32 GB memory > OS is Linux Redhat 64bit 5.1 > Oracle Berkeley DB is 4.7 > The server has 5 DBs. The whole setup has a second master in identical config > with multi-master replication and 2 slaves. > The 2 main DBs have 30 Mio. entries each, the other dbs are very small. > <http://www.openldap.org/faq/data/cache/59.html> p.

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