openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5658) slapo-perl symbol updates
by quanah＠OpenLDAP.org 15 Aug '08

15 Aug '08

Full_Name: Quanah Gibson-Mount Version: 2.4.11 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.109.79.65) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495069 Not sure how much we care about hppa architecture. As described in the 'perlembed' document, programs embedding Perl must use the PERL_SYS_INIT3() and PERL_SYS_TERM() macros to provide system-specific tune up of the C runtime environment necessary to run Perl interpreters. Your package has been identified as failing this: - at least one of the binary packages built from the source depends on libperl5.10 - the unpacked source matches 'perl_parse' but not 'PERL_SYS_INIT3' As a consequence, the embedded Perl interpreter is most probably broken on the hppa architecture, where PERL_SYS_INIT3() is needed for initializing lock structures. Without this, calling perl_parse() will hang inside pthread_mutex_lock(). See #486069 for more information.

1 0

(ITS#5657) Broken symlinks in /etc/ssl/certs prevent ssl connection
by Martin.vGagern＠gmx.net 15 Aug '08

15 Aug '08

Full_Name: Martin von Gagern Version: 2.3.43 OS: Gentoo Linux URL: https://bugs.gentoo.org/show_bug.cgi?id=234816 Submission from: (NULL) (84.188.31.84) On systems with broken symlinks in the default certificate directory of openssl, I found it impossible to establish an ldaps connection with openldap. I originally reported this issue as https://bugs.gentoo.org/show_bug.cgi?id=234816 I first encountered this when I got informed by luma that I could not connect to a server. I then reproduced this on the command line: $ ldapsearch -H ldaps://ldap.domain.tld ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) $ ldapsearch -d 15 -H ldaps://ldap.domain.tld ... ldap_connect_timeout: fd: 3 tm: -1 async: 0 TLS: could not load client CA list (file:`',dir:`/etc/ssl/certs/'). TLS: error:0906D06C:PEM routines:PEM_read_bio:no start line pem_lib.c:647 ... previous line repeated 13 times ... TLS: error:02001002:system library:fopen:No such file or directory bss_file.c:356 TLS: error:20074002:BIO routines:FILE_CTRL:system lib bss_file.c:358 ldap_perror ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Sadly it does not say what file can't be opened. The "no start line" errors seem to be non-fatal. The fopen error in bss_file.c from dev-libs/openssl on the other hand seems to cause the connection to fail. Root of the cause seemed to be several broken symlinks in /etc/ssl/certs. Steps to solve the issue by removing those links: # find /etc/ssl/certs -type l ! -xtype f ! -xtype d -ok rm -f {} \; Steps to reproduce the issue, provided you have an SSL-Enabled LDAP server: # ln -s bar.pem /etc/ssl/certs/foo.pem $ ldapsearch -d 15 -H ldaps://ldap.domain.tld Ideally openldap should trat these errors as non-fatal, the way s_client does, so that such a broken symlink won't prevent all connections. If that path towards solution proves infeasible (as the openssl function SSL_add_dir_cert_subjects_to_stack seems to behave this way and adding all files manually might be a pain), at least there should be some error message telling the user that the problem lies in the local SSL certificates setup, not really in the network connection or remote configuration. By the way, I'm using openssl version 0.9.8h.

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by guenther+ldapdev＠sendmail.com 14 Aug '08

14 Aug '08

On Thu, 14 Aug 2008, Michael Ströder wrote: > Philip Guenther wrote: ... > > They also have the "SSLProtocol" directive, further down on that page. > > Then I'd vote for doing it exactly like this with one option (space- or > comma-separated list of protocols). As I mentioned in the ITS, I think treating the various protocol versions as independently choosable is a Bad Thing, as it permits broken settings with no corresponding gain. That said, it's more important to me that *some* option gets in so that I (and Sendmail) don't have to maintain forever a patch to add it. If someone 'official' will make a decision and simply state what the option should look like in its three forms (C API, ldap.conf, slapd config), I'll munge the patch to match. Philip Guenther

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ghenry＠OpenLDAP.org 14 Aug '08

14 Aug '08

----- "ali pouya" <ali.pouya(a)free.fr> wrote: > Gavin Henry <ghenry(a)suretecsystems.com> wrote : > > > ali.pouya(a)free.fr wrote: > > > Why do you change serverID? > In a configuration with two mirrors I have to set two different IDs. > The problem > is that the replica defaults to serverID=0, whilst I understood that > the replica > does not need a serverID. > > So you're saying serverID=0, serverID=1, serverID=2 makes a > difference > > from serverID=1, serverID=2, serverID=3? > > > > They only have to be unique. > > > > Yes. Let me put the problem another way : > > In 2.4.11 each time you start slapd (master as well as replica) it > scans (reads) > all of the objects being more recent than its contextCSN value having > ITS OWN > serverID. Wouldn't it be bettre that it scans only the objects more > recent thant > the moste recent value of the contextCSN ? > If y have millions of such entries the scanning taks too long. > Is this a bug or a normal feature ? This is intended: servers/slapd/overlays/syncprov.c in HEAD 615 | case FIND_MAXCSN: 616 | | cf.f_choice = LDAP_FILTER_GE; 617 | | /* If there are multiple CSNs, use the one with our serverID */ 618 | | for ( i=0; i<si->si_numcsns; i++) { 619 | | | if ( slap_serverID == si->si_sids[i] ) { 620 | | | | maxid = i; 621 | | | | break; 622 | | | } 623 | | } 624 | | if ( i == si->si_numcsns ) { 625 | | | /* No match: this is multimaster, and none of the content in the DB 626 | | | * originated locally. Treat like no CSN. 627 | | | */ 628 | | | return LDAP_NO_SUCH_OBJECT; 629 | | } > > > There are no writes above, you've only shown searches. > > Yes there are no writes because this is an extract of the startup > log. > > > How many times do you restart slapd and why? > > In production I restart slapd once a day for backup. But the problem > is that if > I restart it for any reason I have to wait to much for the service to > be > available. A cold backup of the bdb dir I take it. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5656) Bind operations with translucent overlay
by mateusz.kijowski＠gmail.com 14 Aug '08

14 Aug '08

Full_Name: Mateusz Kijowski Version: 2.3.43 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.126.222.22) In some use scenarios, it is useful if the translucent overlay does not forward bind operation requests to the remote server when there are values for userPassword attribute in the local database. It would be nice if this could be enabled or disabled by a configuration option. For consistency, enabling this behavior should also affect the PASSMOD extended operation to modify the local value of userPassword.

1 0

Re: (ITS#5578) sortvals error
by andrew.findlay＠skills-1st.co.uk 14 Aug '08

14 Aug '08

On Sat, Jul 05, 2008 at 09:31:28PM +0000, hyc(a)symas.com wrote: > Thanks for the report. Seems the search routine wasn't copied correctly from > back-bdb/idl.c. Fixed now in HEAD. Not quite I'm afraid. It now crashes if a value is added that sorts to the head of the list. I applied this LDIF to the original test case data: dn: cn=tenK,ou=groups,o=test,dc=example,dc=org changetype: modify add: member member: uniqueIdentifier=a_0,dc=example,dc=org Running the server with '-d 65535' the trace ends thus: <= entry_decode(cn=tenK,ou=groups,o=test,dc=example,dc=org) bdb_modify: cn=tenK,ou=groups,o=test,dc=example,dc=org slap_queue_csn: queing 0xa74b3c42 20080814122245.470522Z#000000#000#000000 bdb_dn2entry("cn=tenk,ou=groups,o=test,dc=example,dc=org") bdb_modify_internal: 0x00000004: cn=tenK,ou=groups,o=test,dc=example,dc=org <= acl_access_allowed: granted to database root bdb_modify_internal: add member dnMatch 5 "uniqueIdentifier=a_004997,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_004995,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_000001,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_000000,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_004997,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_004995,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_000001,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_000000,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" Program received signal SIGSEGV, Segmentation fault. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 14 Aug '08

14 Aug '08

Gavin Henry <ghenry(a)suretecsystems.com> wrote : > ali.pouya(a)free.fr wrote: > Why do you change serverID? In a configuration with two mirrors I have to set two different IDs. The problem is that the replica defaults to serverID=0, whilst I understood that the replica does not need a serverID. > > So you're saying serverID=0, serverID=1, serverID=2 makes a difference > from serverID=1, serverID=2, serverID=3? > > They only have to be unique. > Yes. Let me put the problem another way : In 2.4.11 each time you start slapd (master as well as replica) it scans (reads) all of the objects being more recent than its contextCSN value having ITS OWN serverID. Wouldn't it be bettre that it scans only the objects more recent thant the moste recent value of the contextCSN ? If y have millions of such entries the scanning taks too long. Is this a bug or a normal feature ? > There are no writes above, you've only shown searches. Yes there are no writes because this is an extract of the startup log. > How many times do you restart slapd and why? In production I restart slapd once a day for backup. But the problem is that if I restart it for any reason I have to wait to much for the service to be available. I hope I have have understood and answered to your quetions. Thanks Best Regards Ali

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by michael＠stroeder.com 14 Aug '08

14 Aug '08

Philip Guenther wrote: > On Thu, 14 Aug 2008, Michael Ströder wrote: > ... >> From my understanding this is what LDAP_OPT_X_TLS_CIPHER_SUITE is for, >> isn't it? It's directly passed to OpenSSL and can also be used to enable >> or disable SSLv2, SSLv3 and TLSv1 besides choosing the ciphers itself. > > Nope. The cipher suite list and protocol versions supported are > orthogonal: even if you include "!SSLv2" in your cipher suite, openssl > will still send an SSLv2-compatible handshake. Ditto on the server side: > when OpenSSL announced a vulnerability in the server SSLv2 handshake code, > I looked at whether specifying "!SSLv2" in the cipher spec would protect > the server as a workaround. Nope: only setting the SSL_OP_NO_SSLv2 option > or using a SSLv3-only or TLSv1-only method would do it. Ok. >> Apache HTTP server does it also that way. See: >> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite > > They also have the "SSLProtocol" directive, further down on that page. Then I'd vote for doing it exactly like this with one option (space- or comma-separated list of protocols). Ciao, Michael.

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by guenther+ldapdev＠sendmail.com 13 Aug '08

13 Aug '08

On Wed, 13 Aug 2008, Howard Chu wrote: > Philip Guenther wrote: ... > > OpenSSL's API for this is a bitfield with symbolic names, so there > > would still need to be a maintained mapping from whatever schema > > OpenLDAP provided to that bit set. > > Yes, but there's no forward compatibility impact from this. I.e., if we > have to map numbers to bitfields, we can just have a default case: if > the number is higher than any we recognize, just disable all the bits we > know about and assume the TLS library is smart enough to do something > useful with whatever is left. Hmm, with a warning in the docs "if you set this option to a value beyond the range understood by your version of OpenLDAP or the underlying SSL library, it may enforce a lower minimum or fail completely". So instead of writing TLS_PROTOCOL_MIN TLSv1.0 they would write TLS_PROTOCOL_MIN 3,1 etc? I guess that's acceptable to me, albeit a little user unfriendly. > > I guess an alternative would be to directly expose the > > SSL_CTX_set_options() API: TLS_OPTIONS would take a number and pass it > > directly to that call. Of course, the admin would have to read the .h > > file and do some math to figure out what to set, and there's no guarantee > > that OpenSSL won't change those values across a version change... > > I think at this point we need to get away from using implementation-specific > values. Back when OpenSSL was the only game in town I wouldn't have worried > too much about it, but now it's becoming more of an issue. I guess I shouldn't have left out the "<joke>" brackets around that. Philip

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by hyc＠symas.com 13 Aug '08

13 Aug '08

Philip Guenther wrote: > On Wed, 13 Aug 2008, Howard Chu wrote: >> This should use a single option flag and a numeric or bitfield argument >> for selecting protocols instead. Since we're talking about minimum >> settings, it should likely just be an increasing range of numbers. >> >> I note that the on-the-wire protocol version is just a 16 bit integer; >> we could define protocol names that correspond directly to these values. > > OpenSSL's API for this is a bitfield with symbolic names, so there would > still need to be a maintained mapping from whatever schema OpenLDAP > provided to that bit set. Yes, but there's no forward compatibility impact from this. I.e., if we have to map numbers to bitfields, we can just have a default case: if the number is higher than any we recognize, just disable all the bits we know about and assume the TLS library is smart enough to do something useful with whatever is left. > I guess an alternative would be to directly expose the > SSL_CTX_set_options() API: TLS_OPTIONS would take a number and pass it > directly to that call. Of course, the admin would have to read the .h > file and do some math to figure out what to set, and there's no guarantee > that OpenSSL won't change those values across a version change... I think at this point we need to get away from using implementation-specific values. Back when OpenSSL was the only game in town I wouldn't have worried too much about it, but now it's becoming more of an issue. -- -- 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

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