openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 13 Jan '15

13 Jan '15

--On Tuesday, January 13, 2015 6:52 PM +0000 freebsd(a)jonathanprice.org wrote: > Full_Name: Jonathan Price > Version: 2.4.40 > OS: FreeBSD 10.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.47.105.54) > > > I have compiled version 2.4.40 with the SHA2 module enabled. > > I then run the slappasswd with the following arguments: > slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o > module-load=pw-sha2 You requested a non salted hash -> SHA512 Did you try requesting a salted hash? -> SSHA512 Works fine for me, and I've been using it in production for quite some time. [zimbra@zre-ldap003 ~]$ /opt/zimbra/openldap/sbin/slappasswd -h '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o module-load=pw-sha2 -s test {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 13 Jan '15

13 Jan '15

Full_Name: Jonathan Price Version: 2.4.40 OS: FreeBSD 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.47.105.54) I have compiled version 2.4.40 with the SHA2 module enabled. I then run the slappasswd with the following arguments: slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 This works successfully, and in this example I used the word "test" and it produced the following output: {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUNzLDBMxfqa2Ob1f1ACio/w== However, if I replace {SHA512} with {SSHA512} it produces the following output: Password verification failed. I have tested SHA256 SHA384 and SHA512. All three of these work fine. All three of SSHA256, SSHA384 and SSHA512 do not work however. It appears that there is an issue with slappasswd and salted SHA2 hashes. I have checked that 2.4.40 is new enough to have a version of the SHA2 overlay, and also checked the source to make sure it was definitely a new enough version, and can confirm that it is. Unfortunately, beyond this basic level of checking, I'm not a C programmer so I can't investigate the issue further myself.

1 0

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by h.b.furuseth＠usit.uio.no 13 Jan '15

13 Jan '15

On 13/01/15 17:54, leo(a)yuriev.ru wrote: > 2015-01-13 13:50 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: >> comp.programming.threads's advise is that volatile is useless for thread >> sync: You need sync primitives, and then you don't need volatile since >> the compiler/hardware may not move the memory access past the primitive. > > Excuse me, but seems you are misunderstand comp.programming.threads in > case of blocking/locking multithreading and non-blocking > multithreading (aka lock-free/wait-free). Yes, that didn't come out right. I don't mind inserting the volatile, but I don't know that it helps either. As far as I understand if it was broken without volatile, then it's still broken with it - just hopefully less likely to break. And LMDB couldn't be releaseed with your original unportable sync code along with the volatile. > (...) >> Unless the primitive's spec says so, I guess. E.g. with an "asm" >> statement where the compiler does not know what the assembly code does >> and must be told not to mess with ordering. > > Please study GCC's manual about __asm __volalile (:::"memory"), this > is just a "full compiler fence". Thanks, looks good. Will read the rest later. -- Hallvard

1 0

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by leo＠yuriev.ru 13 Jan '15

13 Jan '15

2015-01-13 13:50 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > On 01/12/2015 07:15 PM, leo(a)yuriev.ru wrote: >> >> Unfortunately IMDB programmed without accounting possibility of memory >> reordering and cache incoherency (as a proof - the 'volatile' was >> missed before ITS#7969). >> So, currently seems LMDB is durable only on x86 and may be on MIPS. > > > I gather "volatile" in thread code can be read as "warning: dubious > code" or at best "please access this sooner rather than later". > > comp.programming.threads's advise is that volatile is useless for thread > sync: You need sync primitives, and then you don't need volatile since > the compiler/hardware may not move the memory access past the primitive. Excuse me, but seems you are misunderstand comp.programming.threads in case of blocking/locking multithreading and non-blocking multithreading (aka lock-free/wait-free). Yes, `volatile` don't needed, when a locking (e.g. mutex) is used for access to any variables that shared between threads. But LMDB don't uses locking primitives for interaction between writers and readers. LMDB properties declared as: - readers don't block writers and writers don't block readers; - read transactions are extremely cheap, and can be performed using no mallocs or any other _blocking_ calls; THEREFORE 'volatile' and memory-ordering ISSUES MUST BE HANDLED VERY CAREFULLY AND ANXIOUSLY. > Unless the primitive's spec says so, I guess. E.g. with an "asm" > statement where the compiler does not know what the assembly code does > and must be told not to mess with ordering. Please study GCC's manual about __asm __volalile (:::"memory"), this is just a "full compiler fence". > The best fix is likely a format change which reduces the need for sync > primitives, for LDMBv2. Checksum the MDB_meta, and/or replace the > variable part with a single word which refers to the meta. > Don't know if we can get rid of unportable sync code though. Yes it is possible, but requires C++, see http://en.cppreference.com/w/cpp/atomic/memory_order By using just C, include C99 - not possible, see http://stackoverflow.com/questions/27301371/memory-order-consistency-model-… > Leaving the rest to Howard, I'm too busy just now to do more than blow > hot air:-) Ok ;) I created gist for public review, please share it. https://gist.github.com/leo-yuriev/ba186a6bf5cf3a27bae7 Leonid.

1 0

Re: (ITS#8018) a lot of warnings building with -Wall
by h.b.furuseth＠usit.uio.no 13 Jan '15

13 Jan '15

On 01/12/2015 05:22 PM, leo(a)yuriev.ru wrote: > 2015-01-12 17:19 GMT+03:00 Hallvard Breien Furuseth < > h.b.furuseth(a)usit.uio.no>: >> The Debug() change is going to give merge conflicts all over >> the place when your <https://github.com/ReOpen/ReOpenLDAP> and >> OpenLDAP pull updates from each other. >> >> https://github.com/ReOpen/ReOpenLDAP should not be used for merge, but > only for cherry-picking. Oops, right. "cherry-picking conflicts":-) > It has stripped history and merged with OpenLDAP/mdb.master, because > mdb.RE/0.9 don't includes a few critical fixes (ITS 7969,7970,7971) for our > case. > I think that is the reason for patch conflicts. > Patchset got RE25 should remain among my sent emails. Presumably I can send > it for you again, if you are interested. No, I was talking about maintaining the two projects in the future. Presumably you'll want to copy fixes from OpenLDAP, and we'll want fixes from you. Any such change next to a Debug() statement will not apply cleanly, and must be hand-edited. >> How about defining Debug1(), Debug2(), etc for 1,2... arguments? >> That's still annoying, but it keeps the code C90-compatible and >> keeps -Wformat quiet. There's already similar code for Log<N>() >> in include/ldap_log.h, but it was never used much or even merged >> into RE24. (Because it got scheduled for RE25 which was going to >> start Real Soon Now, IIRC:-) > > IMHO the Log<N> recipe is onerously for support. > On other hand, nowadays all non-obsolete compilers support most of C99 > features. > Baseline features, such as "variadic macro", supported long ago (Microsoft > was the most conservative to 2012). > Maybe it is time to enable C99 in RE25? Dunno. People do use old compilers. OpenLDAP is conservative about portability. It requires C90 to build, but exports K&R1-compatible headers. Well, it tries. K&R1 compat was broken by OpenLDAP 2.0 (ITS#6171) and nobody who cares about K&R1 has bothered to fix it. When we do move towards C99, maybe we'll first test the waters by making Debug() use __VA_ARGS__ but not change the Debug() calls yet, so we'll only have a few lines to revert it it proves premature. We'll hear what Kurt says. -- Hallvard

1 0

Re: (ITS#8022) Backend Meta does not work with ssl-backends
by dirk.kastens＠uni-osnabrueck.de 13 Jan '15

13 Jan '15

Hi, > I've pushed fixes for both of these problems to git master and back-meta > works on ldaps:// for me now. Since I didn't reproduce your symptoms, I > have no idea if this will improve things for you or not. Please test and > follow up, thanks. Great! This perfectly works for me. I just compiled the latest git version. Now the meta directory works with ldaps. Thanks for your support. -- Dirk Kastens Universitaet Osnabrueck, Rechenzentrum (Computer Center) Albrechtstr. 28, 49069 Osnabrueck, Germany Tel.: +49-541-969-2347, FAX: -2470

1 0

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by h.b.furuseth＠usit.uio.no 13 Jan '15

13 Jan '15

On 01/12/2015 07:15 PM, leo(a)yuriev.ru wrote: > Unfortunately IMDB programmed without accounting possibility of memory > reordering and cache incoherency (as a proof - the 'volatile' was > missed before ITS#7969). > So, currently seems LMDB is durable only on x86 and may be on MIPS. I gather "volatile" in thread code can be read as "warning: dubious code" or at best "please access this sooner rather than later". comp.programming.threads's advise is that volatile is useless for thread sync: You need sync primitives, and then you don't need volatile since the compiler/hardware may not move the memory access past the primitive. Unless the primitive's spec says so, I guess. E.g. with an "asm" statement where the compiler does not know what the assembly code does and must be told not to mess with ordering. The best fix is likely a format change which reduces the need for sync primitives, for LDMBv2. Checksum the MDB_meta, and/or replace the variable part with a single word which refers to the meta. Don't know if we can get rid of unportable sync code though. Leaving the rest to Howard, I'm too busy just now to do more than blow hot air:-) -- Hallvard

1 0

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by leo＠yuriev.ru 13 Jan '15

13 Jan '15

2014-11-16 0:04 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > __sync_synchronize() needs an #ifdef around it. > #ifdef __GNUC__, or something more general? I have implemented 'portable' memory barriers for a set of compilers. https://github.com/ReOpen/ReOpenLDAP/commit/a1ec3a4a8290c84846b4e98ff3abf38… Feedback welcomed. Leonid.

1 0

Re: (ITS#8022) Backend Meta does not work with ssl-backends
by hyc＠symas.com 12 Jan '15

12 Jan '15

Dirk Kastens wrote: > Hi, > >> How about running ldapsearch with -d7, and also the corresponding search >> against back-meta using slapd -d7. Upload the output somewhere that we >> can review. > > See ftp.openldap.org/incoming/... > > You will find the following files: > > ldapsearch_direct: directly searching the source server with ssl > > ldapsearch_meta_starttls: searching the meta directory where the source > server is connected via starttls (this works) > > ldapsearch_meta_ssl: searching the meta directory where the source > server is connected via ssl (this doesn't work) > > slapd_meta_starttls: meta directory where the source server is connected > via starttls (this works) > > slapd_meta_ssl: meta directory where the source server is connected via > ssl (this doesn't work). slapd hangs after searching and has to be > killed with "kill -4". > > Hope this helps. > I wasn't able to exactly reproduce the problem shown in your logs, but I did find a couple of problems here. For ldaps:// URLs, the back-meta config parser was ignoring the TLS settings. As such, it wasn't able to establish any ldaps session at all, unless there were usable settings in ldap.conf/ldaprc/etc... Also, back-meta was specifying that libldap should open its outbound connections asynchronously, and this wasn't working properly if the async connection succeeded immediately. (I.e., when told to open async, libldap would expect the connection to take a long time to complete, and defer the rest of initialization to a following library call. If it completed immediately, libldap would mis-handle the rest of initialization.) I've pushed fixes for both of these problems to git master and back-meta works on ldaps:// for me now. Since I didn't reproduce your symptoms, I have no idea if this will improve things for you or not. Please test and follow up, thanks. -- -- 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#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by leo＠yuriev.ru 12 Jan '15

12 Jan '15

2014-11-16 0:04 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > __sync_synchronize() needs an #ifdef around it. > #ifdef __GNUC__, or something more general? > > Not sure what to do for the #else. We could mostly > avoid using mm_txnid when the lockfile is initialized > and use mti_txnid instead (e.g. in pick_meta). And > penalize MDB_NOLOCK with some sync call in the #else. > > -- > Hallvard > Unfortunately IMDB programmed without accounting possibility of memory reordering and cache incoherency (as a proof - the 'volatile' was missed before ITS#7969). So, currently seems LMDB is durable only on x86 and may be on MIPS. I think memory-ordering (e.g. barriers) functions should be defined in separate h-file, which will select implementation depends on cpu-arch & compiler. see http://en.wikipedia.org/wiki/Memory_ordering The minimum seems to be required a memory_barrier_coherence() - to make cache coherence and suppress dangerously load/store reordering, e.g. flush/invalidate cache on some cpu-arch, but do nothing on x86 and so on. Then __sync_synchronize() and MIPS's cache invalidate should be replaced with memory_barrier_coherence(). But instead the original version recreate cleanly on the basis of 1Hippeus engine (manager of shared memory and queues for zero-copy IPC, google it). Leonid

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