openldap-bugs July 2008

openldap-bugs@openldap.org

43 participants
131 discussions

Re: (ITS#5599) slapd dies on erroneous MOD input
by ando＠sys-net.it 12 Jul '08

12 Jul '08

suomi(a)ayni.com wrote: > Full_Name: suomi hasler > Version: 2.4.8-3 > OS: fedora 9 > URL: http://www.ayni.com/slap-prob.txt > Submission from: (NULL) (194.158.243.162) Note that the current release is 2.4.10, and 2.4.11 is about to be released. I couldn't notice any issue in current code after performing erroneous modifications like the one you indicated. Please recheck with the latest release (the pre-release 2.4 from the CVS would be best). 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: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5601) set-acl failure under back-ldap+rwm
by ando＠sys-net.it 12 Jul '08

12 Jul '08

ando(a)sys-net.it wrote: > mbackes(a)symas.com wrote: > > The reason is quite simple: set expansion uses the rewritten DN as the > user's name, so a local lookup of the entry "cn=user,dc=remote" fails > since no local database serves the naming context "dc=remote". The root > cause is that back-ldap binds as the rewritten DN, which is later stored > as the real identity. I think this was done on purpose, and is to some > extent appropriate, but makes the type of ACL you want to design > basically impossible. A solution would be to make slapo-rwm intercept > successful binds (in the cleanup callback) and rewrite back the bound DN > into the virtual naming context. I'll see if it is possible, but then > we need to decide whether this is the desired behavior. Otherwise, we'd > need to have two o_ndn fields: the real DN and the real-real DN. To further elaborate, even if the virtual DN is set instead of the real one in c_ndn, the operation fails because ACL checking passes through bi_entry_get_rw(), which is not provided by slapo-rwm, and can't be provided according to the current design, since it does not allow to massage the arguments. As a quick'n'dirty fix, what you can do is make the proxy database serve both naming contexts, namely database ldap suffix "dc=remote,dc=local" suffix "dc=remote" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret overlay rwm rwm-suffixmassage "dc=remote,dc=local" "dc=remote" This allows the proxy database to be found by select_backend() when searching the right backend using the real naming context. At the same time, internal searches occur as expected. This is a hack; the real fix requires to redesign the API of bi_entry_get_rw(), to let it modify the request arguments while letting the real function do the hard job. 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: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5601) set-acl failure under back-ldap+rwm
by ando＠sys-net.it 12 Jul '08

12 Jul '08

mbackes(a)symas.com wrote: The reason is quite simple: set expansion uses the rewritten DN as the user's name, so a local lookup of the entry "cn=user,dc=remote" fails since no local database serves the naming context "dc=remote". The root cause is that back-ldap binds as the rewritten DN, which is later stored as the real identity. I think this was done on purpose, and is to some extent appropriate, but makes the type of ACL you want to design basically impossible. A solution would be to make slapo-rwm intercept successful binds (in the cleanup callback) and rewrite back the bound DN into the virtual naming context. I'll see if it is possible, but then we need to decide whether this is the desired behavior. Otherwise, we'd need to have two o_ndn fields: the real DN and the real-real DN. 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: ando(a)sys-net.it -----------------------------------

1 0

ldapi:// SASL EXTERNAL on solaris10
by David Markey 11 Jul '08

11 Jul '08

Hi, I'm trying to implement heimdal with an LDAP backend on solaris 10 and im getting issues with authentication when initialising a realm: kadmin> init DMARKEY.COM kadmin: hdb_open: ldap_sasl_bind_s: Authentication method not supported __________________________ ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 send_ldap_result: err=7 matched="" text="SASL(-4): no mechanism available: " connection_get(12) ber_dump: buf=82c5408 ptr=82c5408 end=82c540d len=5 0000: 02 01 02 42 00 slapd.conf(snippet): sasl-secprops minssf=0 sasl-regexp .*uidNumber=0.*,cn=peercred, cn=external,cn=auth uid=heimdal,dc=services,dc=dmarkey,dc=com Would anyone be able to help me? Solaris 10 x86, Heimdal 1.0.2, slapd 2.3.39 I've established this is a solaris specific problem, i compiled everything from scratch on CentOS with the same options and it worked fine. Anyone have any ideas? are sockets different on solaris? Much appreciated.

2 1

Re: (ITS#5593) Back-meta search references
by quanah＠zimbra.com 10 Jul '08

10 Jul '08

--On Thursday, July 10, 2008 1:05 PM +0000 andrew.graham(a)agustawestland.com wrote: > *** Before acting on this email or opening any attachment you are > advised to read the disclaimer at the end of this email *** > > I patched the changes into 2.4.10 and it works perfectly. > > Will this make it into 2.4.11? Yes > If so what is the time frame for release? When we feel it is ready. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5593) Back-meta search references
by andrew.graham＠agustawestland.com 10 Jul '08

10 Jul '08

*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email *** I patched the changes into 2.4.10 and it works perfectly. Will this make it into 2.4.11? If so what is the time frame for release? Thanks for such a fast response! Drew Andrew Graham AgustaWestland UK andrew.graham(a)agustawestland.com >>> <ando(a)sys-net.it> 07/07/2008 20:27 >>> andrew.graham(a)agustawestland.com wrote: > Please provide an option to stop search references being proxied from target to > client in back-meta. "norefs yes" added to HEAD (default "no"). Please test. 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: ando(a)sys-net.it ----------------------------------- *** Disclaimer *** The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If received in error please return to sender immediately. Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence. Westland Helicopters Ltd Lysander Road Yeovil BA20 2YB England Registered in England under No 604352

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by ando＠sys-net.it 10 Jul '08

10 Jul '08

michael(a)stroeder.com wrote: > Kurt Zeilenga wrote: >> Declarations of schema elements should be published as specified in >> RFCs. [..] If caseIgnoreListMatch is not supported, than the >> MatchingRule definition for caseIgnoreListMatch should not be >> published. > > I suspected an answer like this. I've changed my code to also look up > whether the matching rule description itself exists but loose subschema > definitions like this makes it really hard to implement smarter > schema-aware clients. :-/ > > These kind of things would be interesting subjects of interop testing. > >> I note that the specification does allow publication of unimplemented >> descriptions. > > Even worse. :-( Aside from conformity of OpenLDAP's current behavior, I'd consider this ITS as a request to finally implement that matching rule. 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: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by michael＠stroeder.com 10 Jul '08

10 Jul '08

Kurt Zeilenga wrote: > The definitions themselves, such as for postalAddress, should be > generally viewed as immutable. Additionally if a local configuration differs from a RFC you might consider this to be bad practice. But thinking this to the end a server MAY then apply another matching rule to a given attribute type but keep the attribute type description as defined in the RFC. That's even worse because the server behaves differently but the client won't be able to find out. Very bad! Ciao, Michael.

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by michael＠stroeder.com 10 Jul '08

10 Jul '08

Kurt Zeilenga wrote: > Declarations of schema elements should be published as specified in > RFCs. [..] If caseIgnoreListMatch is not supported, than the > MatchingRule definition for caseIgnoreListMatch should not be > published. I suspected an answer like this. I've changed my code to also look up whether the matching rule description itself exists but loose subschema definitions like this makes it really hard to implement smarter schema-aware clients. :-/ These kind of things would be interesting subjects of interop testing. > I note that the specification does allow publication of unimplemented > descriptions. Even worse. :-( Ciao, Michael.

1 0

Re: (ITS#5608) additional info: modify/delete: postalAddress: no equality matching rule
by Kurt＠OpenLDAP.org 10 Jul '08

10 Jul '08

Declarations of schema elements should be published as specified in RFCs. RFC 4512: Servers SHOULD provide definitions of all schema elements they support in subschema (sub)entries. The definitions themselves, such as for postalAddress, should be generally viewed as immutable. Only certain additions (alternative names and extensions can be added, and DESC values changed. Matching rules should never be changed. > If the equality matching rule is not implemented it should not be announced in the subschema. Assuming you mean that the "EQUALITY caseIgnoreListMatch" should be removed, no. If caseIgnoreListMatch is not supported, than the MatchingRule definition for caseIgnoreListMatch should not be published. > The server should not simply report what might have been defined in some RFC. No. See above. I note that the specification does allow publication of unimplemented descriptions. It actually legal to publish caseIgnoreListMatch. But OpenLDAP has traditionally only published supported descriptions.

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2008