January 2017 - openldap-bugs

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech

by michael＠stroeder.com

rick(a)openfortress.nl wrote: > This is in fact what I was looking for; whether OpenLDAP supports this > per-operation Proxy Authz Control. So you can try yourself. The rootdn can always do this. The help of ldapsearch tool says: -e [!]<ext>[=<extparam>] general extensions (! indicates criticality) [..] [!]authzid=<authzid> (RFC 4370; "dn:<dn>" or "u:<user>") Ciao, Michael.

6 years, 2 months

1
0
0 / 0

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech

by rick＠openfortress.nl

Hi Quanah, > Thanks for the report. However, the EXTERNAL mechanism is in fact a > SASL mechanism, just implemented directly in OpenLDAP (vs other SASL > mechanisms that OpenLDAP supports via Cyrus-SASL). The location in > the admin guide is correct. Yes, thanks, Howard also pointed that out, and I learnt. > If you read RFC 4370, Section 1 clearly notes that it is a part of > SASL: > > "The Lightweight Directory Access > Protocol [LDAPV3] supports the use of the Simple Authentication and > Security Layer [SASL] for authentication and for supplying an > authorization identity distinct from the authentication identity, > where the authorization identity applies to the whole LDAP session." Ehm, it doesn't actually state that Proxied Authz is part of SASL. It just continues to state that it is on a per-operation basis, and to me it reads like an independent mechanism, at least as far as the protocol is concerned. Although it can be easily imagined that it were to share (lots of) code with SASL EXTERNAL of course, but that would be an implementation choice. Or am I still not reading it correctly? This is in fact what I was looking for; whether OpenLDAP supports this per-operation Proxy Authz Control. Aside from the above being properly located, I am still missing a remark about it in the Manual. Thanks, -Rick

6 years, 2 months

1
0
0 / 0

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech

by quanah＠symas.com

--On Friday, January 06, 2017 7:17 PM +0000 rick(a)openfortress.nl wrote: > Full_Name: Rick van Rein > Version: 2.4 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:980:93a5:1:98ff:3cc8:e968:ded8) > > > Hello, > > I found a nit in the OpenLDAP administrator's guide at > http://www.openldap.org/doc/admin24/guide.html#SASL%20Proxy%20Authorizati > on > > It mentions Proxy Authorization as a facility of SASL, something I never > heard of. It is defined specifically for LDAP in RFC 4370. So the > chapter title, and perhaps its ordering underneath SASL, are not perfect. Hi Rick, Thanks for the report. However, the EXTERNAL mechanism is in fact a SASL mechanism, just implemented directly in OpenLDAP (vs other SASL mechanisms that OpenLDAP supports via Cyrus-SASL). The location in the admin guide is correct. If you read RFC 4370, Section 1 clearly notes that it is a part of SASL: "The Lightweight Directory Access Protocol [LDAPV3] supports the use of the Simple Authentication and Security Layer [SASL] for authentication and for supplying an authorization identity distinct from the authentication identity, where the authorization identity applies to the whole LDAP session." Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 2 months

1
0
0 / 0

Re: (ITS#8563) Documentation inconsistency for syncrepl for mdb

by quanah＠symas.com

--On Saturday, January 07, 2017 8:13 PM +0000 dpa-openldap(a)aegee.org wrote: > Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; > &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1 > 086;&#1074; Version: 2.4.44 > OS: any > URL: > Submission from: (NULL) (141.2.134.77) > > > The manual states in section 5.2.5.8 olcSyncrepl, second last paragraph: > "The syncrepl replication mechanism is supported by the bdb and hdb > backends". > > This text above is repeated in section 6.2.3.7 syncrepl. > > But in section 18.1.1.2. Syncrepl Details, fourth paragraph, is written > 'The syncrepl engine, which is a consumer-side replication engine, can > work with any backends. The LDAP Sync provider can be configured as an > overlay on any backend, but works best with the back-bdb back-hdb, or > back-mdb backends.' > > Can syncrepl work with any backend and does it work with bdb equally good > as with mdb? Fixed to mention back-mdb/mdb where appropriate. At the time the documentation was written, back-mdb didn't exist. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 2 months

1
0
0 / 0

Re: (ITS#8562) Typos in the documentation

by quanah＠symas.com

--On Saturday, January 07, 2017 7:24 PM +0000 dpa-openldap(a)aegee.org wrote: > Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; > &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1 > 086;&#1074; Version: 2.4.44 > OS: any > URL: > Submission from: (NULL) (141.2.134.77) > > > In the manual, > - section 8.2.5 Access Control Examples, 2nd paragraph replace "allows > anonymous to authentication against these entries" with "authenticate"; > - section 13.2.4 Attibute Type Specification, 4th code snippet, replace > "DESC 'common name(s) assciated with the object" with "associated"; > - section8.8.1.1 LDAP Sync Replication, last paragraph, replace "is > defined by a general search criteria consisting of base and scope': > remove the 'a' in front of criteria. > - section 20 Monitoring, 3rd paragraph "This information can be access > with ldapsearch", substitute with "accessed". Fixed, thanks, outside of the "a general search criteria consisting of base and scope". That seems correct to me. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 2 months

1
0
0 / 0

Re: (ITS#8570) Typo in LDAP_STAILQ_ENTRY_INIT

by quanah＠symas.com

--On Tuesday, January 17, 2017 11:49 AM +0000 okuznik(a)symas.com wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: > URL: > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170117-ldap_queue-STAILQ. > patch Submission from: (NULL) (151.228.185.198) > > > There is a typo in include/ldap_queue.h:227, where the macro arguments do > not match with the content. Patch attached. Thanks for the report! This will be a part of the 2.4.45 release. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years, 2 months

1
0
0 / 0

(ITS#8570) Typo in LDAP_STAILQ_ENTRY_INIT

by okuznik＠symas.com

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170117-ldap_queue-STAILQ.... Submission from: (NULL) (151.228.185.198) There is a typo in include/ldap_queue.h:227, where the macro arguments do not match with the content. Patch attached.

6 years, 2 months

1
0
0 / 0

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT

by michael＠stroeder.com

william.b.clay(a)acm.org wrote: > By localhost, I simply meant running the LDAP client I am developing on > the same host as slapd. To test the same code on different client > hosts, the coded test URIs always specified the server's FQDN. So you're using TLS client cert and SASL/EXTERNAL to a hostname (also in ther server cert) but where the IP address of the hostname is directly routed through 127.0.0.1? > The same tests over the same client code running on a different host > than slapd never got SEGFAULTs -- which I find curious given the nature > of that little bug. There must be some difference in OS memory > allocation logic applied in the two cases. Not sure but the difference is the client IP address. If the client can reach slapd through 127.0.0.1 the client's IP address is also 127.0.0.1 which could make a difference in the SASL client handling. Anyone said hostname canonicalization? Does setting sasl-host <fqdn> make a difference? > I recognize EXTERNAL may not be heavily used, although it's quite useful > in the environment I'm supporting. Actually I'm heavily using SASL/EXTERNAL in almost all my customer setups and in Æ-DIR using either LDAPI:// with Unix Peer Credential passing or TLS with client certs (e.g. for replication). Therefore I appreciate every fix going into this. :-) Ciao, Michael.

6 years, 2 months

1
0
0 / 0

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT

by william.b.clay＠acm.org

By localhost, I simply meant running the LDAP client I am developing on the same host as slapd. To test the same code on different client hosts, the coded test URIs always specified the server's FQDN. The same tests over the same client code running on a different host than slapd never got SEGFAULTs -- which I find curious given the nature of that little bug. There must be some difference in OS memory allocation logic applied in the two cases. I recognize EXTERNAL may not be heavily used, although it's quite useful in the environment I'm supporting. I was simply doing exhaustive testing of my client code under all combinations of transport and authentication. With this bug plugged and using Cyrus SASL 2.1.26 at both ends (2.1.25 has a memory leak for my client), EXTERNAL runs fine in all cases: client local or remote; URI ldapi:// (auth on gid/uid), ldaps:// (auth on cert subject user DN), or ldap:// w/ startTLS (idem).

6 years, 2 months

1
0
0 / 0

Re: (ITS#8568) slapd SASL EXTERNAL bind getprop SSF bug; can provoke SEGFAULT

by michael＠stroeder.com

william.b.clay(a)acm.org wrote: > In certain circumstances (e.g., two successive localhost EXTERNAL binds Just to be sure: What do you mean with "localhost" in this context? Really ldap://localhost or ldapi://? SASL EXTERNAL most times only makes sense in the latter case (unless you've configured a TLS certificate with name "localhost"). Ciao, Michael.

6 years, 2 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2017