openldap-devel November 2017

openldap-devel@openldap.org

4 participants
7 discussions

asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder 04 Nov '21

04 Nov '21

hyc(a)symas.com wrote in ITS#8240: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. > Closing this ITS, not an OpenLDAP bug. Maybe I missed something. But this is the first time I've heard about -DNDEBUG being mandatory when compiling binary packages for production use. Does it have other effects? And what are general rules for assert statements in OpenLDAP code? In my own (Python) code assert statements are supposed to be only triggered if something goes wrong *internally* (type issues etc.). If somebody manages to trigger an assert statement with invalid input from "outside" I always consider this to be a serious bug revealing insufficient error handling even though e.g. web2ldap just logs the exception but won't crash. YMMV, but please clarify. I also wonder whether there are more mandatory rules for building packages and where I can find them. Please don't get me wrong: My inquiry is in good faith to avoid unnecessary ITS based on misunderstanding. Ciao, Michael.

1 1

VC exop and LDAPWhoAmI?
by Ondřej Kuzník 19 Jan '18

19 Jan '18

Trying to get SASL bind support into the Load Balancer now and a bit stuck when it comes to figuring out what the resulting authorisation identity is (SASL or LDAP say it's backend specific) for use with the proxyauthz control. Passing the binds on is the simple one, we can just send an LDAPWhoAmI after a successful result and we're set. If the backends support the VC extended operation, we want to use that, since that doesn't necessarily tie up a connection for each active bind. In that case, there is no way to get the authzId out. What is the best way to amend the VC spec? I would think adding another optional boolean field "return authzid" might be preferable. Setting it would have the server return a new field in the response containing the authorisation identity (maybe letting the server return it anyway, but that mightn't do good things to backward compatibility). A new control might be another option, that control could then be attached to bind requests as well I guess to obviate the need to send LDAPWhoAmI afterwards. This might be of use for applications that have a similar usecase: use VC Exop and then attach the proxyauthz control to operations performed on each of its client's behalf. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 1

Approaches to ITS#8772
by Ondřej Kuzník 24 Nov '17

24 Nov '17

If we add an expectation that recursive and simple mutexes can be (un)locked in the same way, we can remove the function aliases without incurring the useless duplication. The only target that would be affected is mach cthreads since it allegedly doesn't support recursive mutexes natively. I don't think it exists as a viable target any more (for instance, there is hardly any documentation to be found about it), so I'm inclined to stop supporting it anymore. So the proposed way to deal with it would be as follows: 1. Remove mach cthreads support 2. Remove the type distinction between the mutex types and drop recursive mutex (un)locking functions 3. Update accesslog to use the above 4. Drop rmutex.c Any objections? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

ACL checks and slapo-unique
by Michael Ströder 24 Nov '17

24 Nov '17

HI! What really strikes users is the lack of feedback in case a unique constraint or other constraint fails. Let's look at error messages of slapo-unique first. I'm experimenting with a pretty simple patch for returning the effective uniqueness filter in the diagnosticMessage. Example output with this patch (line wrapped): $ ldapadd -f test.ldif adding new entry "uid=foo,ou=Users,dc=example,dc=com" ldap_add: Constraint violation (19) additional info: non-unique attributes found with (|(uid=foo)(uidNumber=20000)) Even this minimum information is already somewhat useful. Of course it would be even more nice to get the list of non-unique attribute values returned. (I vaguely remember some idea for a "What Failed?" response control.) Now formerly one of the arguments against returning more information in the diagnosticMessage was that this would reveal content information to an attacker which is obtained by an internal search with a more privileged authz-ID. Yes, that's right. But this problem exists anyway because an attacker can probe values by adding entries with non-unique attributes and determine whether an attribute value exists or not by distinguishing the result code constraintViolation(19) vs. insufficientAccessRights(50). Even worse this even works in case the attacker does not have read access anywhere! This leads to the question whether some sort of access control or limit check should be applied in unique_search(). What do you think? Ciao, Michael.

2 2

Component Matching, ASN.1 compiler
by Howard Chu 14 Nov '17

14 Nov '17

The component matching feature has been pretty much broken and unmaintained for quite a while. Part of the problem is the existing code uses the eSNACC ASN.1 compiler, which is total abandonware and has been for a long time. It was pointed out to me that the Heimdal project includes a full ASN.1 compiler. Would someone be willing to investigate using theirs to replace eSNACC? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: slapd.backends(5)
by Howard Chu 07 Nov '17

07 Nov '17

Quanah Gibson-Mount wrote: > This man page currently lists hdb as the recommended backend (for both 2.4 and > 2.5/HEAD). > > I think at this point, back-mdb is the recommended backend for 2.4 (and > obviously is for 2.5/HEAD). Any objections to me updating the manpage for > 2.4.46 to reflect this? Go ahead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

slapd.backends(5)
by Quanah Gibson-Mount 07 Nov '17

07 Nov '17

This man page currently lists hdb as the recommended backend (for both 2.4 and 2.5/HEAD). I think at this point, back-mdb is the recommended backend for 2.4 (and obviously is for 2.5/HEAD). Any objections to me updating the manpage for 2.4.46 to reflect this? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel November 2017