openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: ITS#6475
by manu＠netbsd.org 24 Feb '10

24 Feb '10

<masarati(a)aero.polimi.it> wrote: > It allows to configure what SASL auxprop names need the "dontUseCopy" > approach. The "cmusaslsecretOTP" is set by default, if known through the > schema. Seems nice. I hope I'll have time to test this week. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: ITS#6475
by masarati＠aero.polimi.it 24 Feb '10

24 Feb '10

A more complete fix is here: <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-24-dontusecopy-…> It allows to configure what SASL auxprop names need the "dontUseCopy" approach. The "cmusaslsecretOTP" is set by default, if known through the schema. Please test. p.

1 0

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 21 Feb '10

21 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

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