asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
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 year, 10 months
VC exop and LDAPWhoAmI?
by Ondřej Kuzník
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
5 years, 8 months
Approaches to ITS#8772
by Ondřej Kuzník
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
5 years, 10 months
ACL checks and slapo-unique
by Michael Ströder
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.
5 years, 10 months
Component Matching, ASN.1 compiler
by Howard Chu
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/
5 years, 10 months
Re: slapd.backends(5)
by Howard Chu
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/
5 years, 10 months
slapd.backends(5)
by Quanah Gibson-Mount
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>
5 years, 10 months
