openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#8937) Possibly wrong MDB_DUPFIXED flag check
by juerg.bircher＠gmail.com 18 Nov '18

18 Nov '18

Full_Name: Juerg Bircher Version: LMDB master OS: macOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.83.86.107) In mdb_cursor_put the flag MDB_DUPFIXED is checked on line 7628 as follows: if ((mc->mc_db->md_flags & (MDB_DUPSORT|MDB_DUPFIXED)) == MDB_DUPFIXED) np->mp_flags |= P_LEAF2; Should it not be like this: if (mc->mc_db->md_flags & MDB_DUPFIXED) np->mp_flags |= P_LEAF2; According to the documentation: * <li>#MDB_DUPFIXED * This flag may only be used in combination with #MDB_DUPSORT. So the expression (mc->mc_db->md_flags & (MDB_DUPSORT|MDB_DUPFIXED)) == MDB_DUPFIXED) would never match.

1 0

(ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password
by michael＠stroeder.com 18 Nov '18

18 Nov '18

Full_Name: Version: 2.4.46 OS: openSUSE Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.240.182.29) SASL bind with SCRAM-SHA-1 does not return invalidCredentials (49) in case of a wrong password being used while DIGEST-MD5 and other password mechs works as expected. This might lead to different error handling in client applications if the user input a wrong password. This proves SCRAM-SHA-1 is enabled and working: $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w test123 SASL/SCRAM-SHA-1 authentication started SASL username: test42 SASL SSF: 0 dn:uid=test42,ou=testing,dc=stroeder,dc=de But wrong password returns other(80) as result code: $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w wrong SASL/SCRAM-SHA-1 authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-5): bad protocol / cancel: StoredKey mismatch Now testing DIGEST-MD5: $ ldapwhoami -Y DIGEST-MD5 -U test42 -w test123 SASL/DIGEST-MD5 authentication started SASL username: test42 SASL SSF: 128 SASL data security layer installed. dn:uid=test42,ou=testing,dc=stroeder,dc=de Wrong password returns invalidCredentials(49) as expected: $ ldapwhoami -Y DIGEST-MD5 -U test42 -w wrong SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: client response doesn't match what we generated (tried bogus)

1 0

Re: (ITS#8935) slapo-ppolicy requires rewrite
by quanah＠symas.com 17 Nov '18

17 Nov '18

--On Saturday, November 17, 2018 11:27 AM +0000 michael(a)stroeder.com wrote: > With such a layout the standard schema shipped with the software is not > part of cn=config but can still be dynamically changed (by directly > modifying subschema subentry). But there's always a way out of trouble > because you can manually fix the separate LDIF schema file(s). You can manually fix the ones stored in cn=config with OpenLDAP now, and you can also change it dynamically. I'm not sure how either of those statements address the problem discussed in this ITS. Quite frankly, I wrote a tool to automatically update the schema stored with cn=config so that it matched whatever was shipped in a given release on upgrade when I worked @ Zimbra: <https://github.com/Zimbra/zm-core-utils/blob/develop/src/libexec/zmldapsche…> I.e., I don't really see what in the above is different from what you can do now, nor do I see how it resolves the issue of a binary compiled file that must have references to valid schema compiled into it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8935) slapo-ppolicy requires rewrite
by quanah＠symas.com 17 Nov '18

17 Nov '18

--On Saturday, November 17, 2018 9:49 AM +0000 michael(a)stroeder.com wrote: > Your conclusion is to hard-code the ppolicy schema into the C code. > If you think this to the end you have to move *all* standard schema > installed to schema_prep.c. The above statement is simply not true. The difference here is the fact that the ppolicy binary has direct references to the schema in its code, which requires it to have matching schema prior to slapd being able to start. You can still start slapd when any schema (outside of the few items hard coded in schema_prep for the same reason) is different. You have the ability at that point to modify slapd via online operations post-upgrade. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8935) slapo-ppolicy requires rewrite
by michael＠stroeder.com 17 Nov '18

17 Nov '18

On 11/17/18 11:35 AM, hyc(a)symas.com wrote: > We could instead ship an update.ldif containing the mods between > different schema versions, that must be applied with slapmodify > during the update process... IMO too many prerequisites must be perfectly full-filled and thus is too fragile. That's one of the things where e.g. OpenDS/OpenDJ does a much better job with its cn=config: The schema shipped with the server is stored in various LDIF files in a config directory along with file rootdse.ldif holding cn=config. Schema directly added by modifying cn=schema is sent to a separate user schema file. With such a layout the standard schema shipped with the software is not part of cn=config but can still be dynamically changed (by directly modifying subschema subentry). But there's always a way out of trouble because you can manually fix the separate LDIF schema file(s). Ciao, Michael.

1 0

Re: (ITS#8935) slapo-ppolicy requires rewrite
by hyc＠symas.com 17 Nov '18

17 Nov '18

michael(a)stroeder.com wrote: > The root cause is that updating slapd with its default schema installed > does not update existing content of cn=schema,cn=config. > > You have to tackle this root cause and not only solve it for a > particular overlay. We could instead ship an update.ldif containing the mods between different schema versions, that must be applied with slapmodify during the update process... -- -- 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#8935) slapo-ppolicy requires rewrite
by michael＠stroeder.com 17 Nov '18

17 Nov '18

The root cause is that updating slapd with its default schema installed does not update existing content of cn=schema,cn=config. You have to tackle this root cause and not only solve it for a particular overlay. Your conclusion is to hard-code the ppolicy schema into the C code. If you think this to the end you have to move *all* standard schema installed to schema_prep.c. IMO this is bad design. But I'm not the one to decide on that. :-/ Ciao, Michael.

1 0

Re: (ITS#8893) New LDAP option to support binding to specific IPv4/IPv6 address at client side
by quanah＠symas.com 16 Nov '18

16 Nov '18

--On Saturday, November 17, 2018 12:14 AM +0000 quanah(a)symas.com wrote: > --On Tuesday, August 07, 2018 5:33 AM +0000 sudhir.singam(a)gmail.com wrote: > >> Full_Name: sudhir reddy singam >> Version: master branch >> OS: fedora >> URL: >> Submission from: (NULL) (131.228.66.13) Never mind, I see this is a duplicate of ITS#8847. Please do not file duplicate ITSes for the same issue. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8893) New LDAP option to support binding to specific IPv4/IPv6 address at client side
by quanah＠symas.com 16 Nov '18

16 Nov '18

--On Tuesday, August 07, 2018 5:33 AM +0000 sudhir.singam(a)gmail.com wrote: > Full_Name: sudhir reddy singam > Version: master branch > OS: fedora > URL: > Submission from: (NULL) (131.228.66.13) > > > > The attached file is derived from OpenLDAP Software. All of the > modifications to > OpenLDAP Software represented in the following patch(es) were developed by > NOKIA. NOKIA has not assigned rights and/or interest in this work to any > party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to > release this work under the following terms. > > NOKIA hereby place the following modifications to OpenLDAP Software (and > only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > **** Hello, There is no patch associated with this ITS. Can you please respond to this email and attach it? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8935) slapo-ppolicy requires rewrite
by quanah＠openldap.org 16 Nov '18

16 Nov '18

Full_Name: Quanah Gibson-Mount Version: OpenLDAP 2.4 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) In OpenLDAP 2.4.43, a new attribute was added to the external ppolicy schema (ITS#8185). While this worked fine with older slapd.conf based configurations where the ppolicy schema file was replaced on upgrade, it was a complete and utter disaster for deployments using cn=config, as the ppolicy overlay references all the attributes defined in external ppolicy schema file. To be able to upgrade without failure, one would have export cn=config, update the binaries, update the ppolicy schema information in the exported cn=config database, re-import cn=config, and then start slapd. This broke the usual ability to do in-place upgrades with cn=config. Instead, the entire contents of the ppolicy.schema file should be internalized to the ppolicy overlay, similar to how the accesslog overlay is written, and the external ppolicy.schema file deleted. This will allow non-breaking upgrades for both slapd.conf and cn=config based configurations.

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