openldap-bugs April 2012

openldap-bugs@openldap.org

36 participants
172 discussions

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 18 Apr '12

18 Apr '12

> No. Your patch fixes one possible wrong outcome, but the sudo > approach is > still fundamentally wrong and if we only patch this one instance, > someone else > in the future is bound to trip over the sequencing problem again. Fix > the > right bug, otherwise you will have to keep fixing the wrong bugs over > and over > again. OK, thanks for confirmation. I will report a bug for sudo. Jan

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by hyc＠symas.com 18 Apr '12

18 Apr '12

Jan Vcelak wrote: >> Sounds like a simple sequencing bug then. Just initialize the global >> options >> before the first ldap_initialize() call. > > Sudo parses the options in config file and stores them in a table: > http://www.sudo.ws/repos/sudo/file/6fa11e8448b9/plugins/sudoers/ldap.c#l225 > > This table is then iterated and all options are being set. The > problem is that some options are set with LDAP handle provided > and some are not. This means that the handle has to be created > before. The change proposed by you would require the change of > this well-arranged and transparent concept. "Elegance" of code does not make it less wrong. The config is simply driven as a list. They can very easily fix this so that sudo_ldap_set_options() is called twice, first with a NULL ld and only the non-connection-oriented parameters, then create the LDAP handle and call again to set the connection-oriented parameters. > It can be a sequencing bug, but this particular situation is not > described anywhere. Perhaps that should be raised as a separate doc bug then. Global options are copied to a handle at the time the handle is created. Any options not explicitly set globally at that time are set to their default value. > And OpenSSL has a different behavior. My patch > updates Mozilla NSS backend to behave the same as OpenSSL backend. > I still think this should be fixed in OpenLDAP rather than in sudo. No. Your patch fixes one possible wrong outcome, but the sudo approach is still fundamentally wrong and if we only patch this one instance, someone else in the future is bound to trip over the sequencing problem again. Fix the right bug, otherwise you will have to keep fixing the wrong bugs over and over again. -- -- 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: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 18 Apr '12

18 Apr '12

> Sounds like a simple sequencing bug then. Just initialize the global > options > before the first ldap_initialize() call. Sudo parses the options in config file and stores them in a table: http://www.sudo.ws/repos/sudo/file/6fa11e8448b9/plugins/sudoers/ldap.c#l225 This table is then iterated and all options are being set. The problem is that some options are set with LDAP handle provided and some are not. This means that the handle has to be created before. The change proposed by you would require the change of this well-arranged and transparent concept. It can be a sequencing bug, but this particular situation is not described anywhere. And OpenSSL has a different behavior. My patch updates Mozilla NSS backend to behave the same as OpenSSL backend. I still think this should be fixed in OpenLDAP rather than in sudo. Jan

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by hyc＠symas.com 18 Apr '12

18 Apr '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-120412-moznss-hostname-check.patch > Submission from: (NULL) (209.132.186.34) > > > Hello. > > With Mozilla NSS crypto backend, the 'tls_checkpeer no' option in 'sudo' tool > does not work. I have uploaded a patch which fixes the bug. > > But some explanation is necessary: > > sudo initially creates a ldap handle using ldap_initialize() function. Then it > uses ldap_set_option() to set all the settings. The TLS configuration is applied > without passing a LDAP handle, which means the the global options are changed. Sounds like a simple sequencing bug then. Just initialize the global options before the first ldap_initialize() call. > In ldap_int_start_tls(): > > - The ldap_int_tls_connect() is called and the global TLS context is used > (LDAP_INT_GLOBAL_OPT()->ldo_tls_ctx). Which is correct. > > - The ldap_pvt_tls_check_hostname() is called always. "sudo" will set the > ldo_tls_require_cert in global options to LDAP_OPT_X_TLS_NEVER, but the handle > options (ld->ld_options) are used to check whether the verification is supposed > to happen. And ldo_tls_require_cert in handle options is LDAP_OPT_X_TLS_DEMAND > (the default), because it was copied from the global options at the time when > ldap_initialize() was called. > > - With OpenSSL, hostname check (tlso_session_chkhost) will succeed because > tlso_get_cert() will return NULL. This is true because no certificate was > requested when connecting. We do not request the certificate as well in Mozilla > NSS, but it seems that the peer can send it anyway and the library will accept > and store it. In this case, hostname check (tlsm_session_chkhost) might fail > because SSL_PeerCertificate() will return it. > > I've added an additional check, which skips the hostname verification within > tlsm_session_chkhost if we do not request the certificate validation. With this > patch, the behavior is consistent with OpenSSL. > > (Maybe ldap_pvt_tls_check_hostname() should not just be called, because the > global context was used and therefore we should use global options. Not sure > what is expected, but I think that changing this might break some applications. > My fix is safer.) > > Jan > > -- -- 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: (ITS#7110) cn=config mixes values
by hyc＠symas.com 17 Apr '12

17 Apr '12

Raphaël Ouazana-Sustowski wrote: > Sorry, that was a typo. > >>> Case 2 (inversed values): >>> >>> dn: olcDatabase={3}bdb,cn=config >>> changetype: modify >>> replace: olcAccess >>> olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write >>> olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write >>> olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write >>> >>> Result: >>> olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write >>> olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write >>> olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write >>> >>> The two last values are incorrectly mixed. >> >> Wrong, this works as designed. See draft-chu-ldap-xordered-xx section >> 3.3. > > I reread intensively this section (xx=00), but I don't find anywhere > where it is specified that lines are read one after one and not > globally. >>>> The ordering-prefix may also be used in Modification requests to specify which values to delete, and in which position values should be added. When processing deletions and insertions, all of the ordinals are recounted after each individual modification. If a value being added does not have an ordering-prefix, it is simply appended to the list and the appropriate ordering-prefix is automatically generated. Likewise if an ordering-prefix is provided that is greater than or equal to the number of existing values. <<<< > Anyway this is not a problem anymore in my software, I modified the > client to send the values in the good order. But I'd like to understand > where it is specified. Else I think this sample case should be added to > the draft. > > Regards, > Raphaël Ouazana. > -- -- 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: (ITS#7248) Cast to string in back-sql when upper_needs_cast is declared in slapd.conf
by rene.snajder＠i-med.ac.at 17 Apr '12

17 Apr '12

Oh, and I forgot: The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Rene Snajder Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#7248) Cast to string in back-sql when upper_needs_cast is declared in slapd.conf
by rene.snajder＠i-med.ac.at 17 Apr '12

17 Apr '12

Full_Name: Rene Snajder Version: 2.4.30 OS: RHEL 6 URL: ftp://ftp.openldap.org/incoming/openldap-upper-strcast.patch Submission from: (NULL) (193.171.77.1) I reported (from my other e-mail address dermaniac(a)gmail.com) a bug report in January. I reported it to the technical mailing list first: http://www.openldap.org/lists/openldap-technical/201201/msg00233.html which I got no reply on. I then posted a ticket here: http://www.openldap.org/its/index.cgi/Incoming?id=7130;page=12 which I got one reply but it didn't fix my problem (and I didn't get further replies). I then took matters in my own hand and found 3 bugs in back-sql which lead to errors when UPPER is applied to integer values. Since there was no reaction here I tried to report it to Redhat (since I'm using RHEL) where the issue finally got some attention. I created a bugfix and they advised me to submit it directly to openldap, so now I'm trying it here again. Strangely, the same day that redhat responded to my patch I got a reply here: http://www.openldap.org/lists/openldap-technical/201204/msg00108.html to which I cannot seem to answer (my mails to the mailing list never seem to make it through). Here are the bugs that I found: 1) It is not checked whether the UPPER function can be applied on a type in the database. Comments in the code itself confirm that this is "currently broken". (see my previous 2 comments) 2) One would assume that the parameter "upper_needs_cast yes" in the slapd.conf would add a string casting statement to every UPPER statement in the SQL queries. In fact, it only does so for one single query (when it queries for "ldap_entries.dn"). All other queries where UPPER is applied still don't use a cast, even though I declare "upper_needs_cast yes" in the main config file. 3) The slapd.conf file lets me declare a "strcast_func" which is the name of the function for a cast to string. This strcast_func is used at some points in the queries, but not consistently. For the one query that actually pays any attention to the "upper_needs_cast" parameter (which i mentioned before) a hardcoded string cast function is used instead. This function is always "(cast ? as varchar(255))". Now these are 3 separate problems in the back-sql code. To fix my particular problem I took a closer look at problem number 2. I attached an patch which can be applied to the version in the GIT repository. When this patch is applied, the hardcoded strcast function from problem number 3 is at least applied to every use of the UPPER function (or at least everywhere where the upper function is applied properly!), effectively fixing problem number 2. This may THEORETICALLY lead to the following problem: IF someone set "upper_needs_cast yes" in their config, with a database backend that does not support the hardcoded strcast function, this patch would break the SQL queries for this user. BUT, in that case using the "upper_needs_cast yes" statement would have been useless - or even causing problems - before this patch anyways - since it was always using the hardcoded function and only at one single point. My patch is here: ftp://ftp.openldap.org/incoming/openldap-upper-strcast.patch For a more detailed description see my bug report in the Redhat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=809105

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 16 Apr '12

16 Apr '12

Howard Chu wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> 4.2.2.2 fedfsFsn >>> IMO name/port should just be an LDAP URL. Also your definition provides >>> absolutely zero information of how the LDAP server should be contacted (e.g. >>> using ldaps or StartTLS) which both can be encoded in an LDAP URL. >> >> Which standard describes how to mandate use of StartTLS with a LDAP URL? >> OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with >> web2ldap. But AFAIK this is not defined in any standard which could be >> referenced in a RFC. > > True but irrelevant. The point is that standardizing on a URL syntax today > future-proofs a spec and allows it to handle new connection mechanisms that > may appear in the future. Host/port is inextricably tied to networking in the > 1980s. I did not want to endorse the use of host/port. I just wanted to point out that one cannot specify the use of StartTLS by LDAP URL in a standard way. Of course nothing prevents somebody to add custom extension to LDAP URLs. Ciao, Michael.

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by hyc＠symas.com 16 Apr '12

16 Apr '12

Michael Ströder wrote: > hyc(a)symas.com wrote: >> 4.2.2.2 fedfsFsn >> IMO name/port should just be an LDAP URL. Also your definition provides >> absolutely zero information of how the LDAP server should be contacted (e.g. >> using ldaps or StartTLS) which both can be encoded in an LDAP URL. > > Which standard describes how to mandate use of StartTLS with a LDAP URL? > OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with > web2ldap. But AFAIK this is not defined in any standard which could be > referenced in a RFC. True but irrelevant. The point is that standardizing on a URL syntax today future-proofs a spec and allows it to handle new connection mechanisms that may appear in the future. Host/port is inextricably tied to networking in the 1980s. > http://www.openldap.org/lists/openldap-devel/200202/msg00060.html > http://www.openldap.org/lists/openldap-devel/200810/msg00034.html > > Ciao, Michael. > -- -- 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: (ITS#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 16 Apr '12

16 Apr '12

hyc(a)symas.com wrote: > 4.2.2.2 fedfsFsn > IMO name/port should just be an LDAP URL. Also your definition provides > absolutely zero information of how the LDAP server should be contacted (e.g. > using ldaps or StartTLS) which both can be encoded in an LDAP URL. Which standard describes how to mandate use of StartTLS with a LDAP URL? OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with web2ldap. But AFAIK this is not defined in any standard which could be referenced in a RFC. http://www.openldap.org/lists/openldap-devel/200202/msg00060.html http://www.openldap.org/lists/openldap-devel/200810/msg00034.html Ciao, Michael.

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
18
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 April 2012