openldap-bugs February 2015

openldap-bugs@openldap.org

28 participants
71 discussions

(ITS#8069) MDb library patch: Use explicit Windows API functions for char* strings
by pmedvedev＠gmail.com 27 Feb '15

27 Feb '15

Full_Name: Pavel Medvedev Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.25.225.40) Most Windows API functions such as CreateFile(), CreateMutex(), OpenMutex() that accept string arguments, are defined with suffix W or A for appropriate wchar_t* or char* strings, depending of _UNICODE preprocessor define. Calling explicit functions with A suffix would eliminate compile errors when _UNICODE is defined. As a further enhancement, I think path argument encoding should be documented (probably UTF-8?) for such functions as mdb_env_open(), mdb_env_copy(), mdb_env_copy2(), and mdb_env_get_path(). This prevent possible problems with non-latin characters in path names on Windows. In this case, LMDB implementation on Windows should perform path conversion to UTF-16 and explicit call to CreateFileW() in mdb_env_open() and mdb_env_copy2() functions. --- libraries/liblmdb/mdb.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index a54ce83..a669da6 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -1409,7 +1409,7 @@ mdb_strerror(int err) ; } buf[0] = 0; - FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM | + FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, err, 0, ptr, sizeof(buf), (va_list *)pad); return ptr; @@ -4413,7 +4413,7 @@ mdb_env_setup_locks(MDB_env *env, char *lpath, int mode, int *excl) off_t size, rsize; #ifdef _WIN32 - env->me_lfd = CreateFile(lpath, GENERIC_READ|GENERIC_WRITE, 909env->me_lfd = CreateFileA(lpath, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); #else @@ -4517,9 +4517,9 @@ mdb_env_setup_locks(MDB_env *env, char *lpath, int mode, int xcxcl) mdb_hash_enc(&val, encbuf); sprintf(env->me_txns->mti_rmname, "Global\\MDBr%s", encbuf); sprintf(env->me_txns->mti_wmname, "Global\\MDBw%s", encbuf); - env->me_rmutex = CreateMutex(&mdb_all_sa, FALSE, env->me_txns->mti_rmname); + env->me_rmutex = CreateMutexA(&mdb_all_sa, FALSE, env->me_txns->mti_rmname); if (!env->me_rmutex) goto fail_errno; - env->me_wmutex = CreateMutex(&mdb_all_sa, FALSE, env->me_txns->mti_wmname); + env->me_wmutex = CreateMutexA(&mdb_all_sa, FALSE, env->me_txns->mti_wmname); if (!env->me_wmutex) goto fail_errno; #elif defined(MDB_USE_SYSV_SEM) unsigned short vals[2] = {1, 1}; @@ -4569,9 +4569,9 @@ mdb_env_setup_locks(MDB_env *env, char *lpath, int mode, int *excl) goto fail; %%D #ifdef _WIN32 - env->me_rmutex = OpenMutex(SYNCHRONIZE, FALSE, env->me_txns->mti_rmname); + env->me_rmutex = OpenMutexA(SYNCHRONIZE, FALSE, env->me_txns->mti_rmname); if (!env->me_rmutex) goto fail_errno; - env->me_wmutex =pepenMutex(SYNCHRONIZE, FALSE, env->me_txns->mti_wmname); + env->me_wmutex = OpenMutexA(SYNCHRONIZE, FALSE, env->me_txns->mti_wmname); if (!env->me_wmutex) goto fail_errno; #elif defined(MDB_USE_SYSV_SEM) semid = env->me_txns->mti_semid; @@ -4686,7 +4686,7 @@ mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode len = OPEN_ALWAYS; } mode = FILE_ATTRIBUTE_NORMAL; - env->me_fd = CreateFile(dpath, oflags, FILE_SHARE_READ|FILE_SHARE_WRITE, + env->me_fd = CreateFileA(dpath, oflags, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, len, mode, NULL); #else if (F_ISSET(flags, MDB_RDONLY)) @@ -4716,7 +4716,7 @@ mdb_env_open(MDB_env *env, const char *path, unsigned int flags, mdb_mode_t mode */ #ifdef _WIN32 len = OPEN_EXISTING; - % e9env->me_mfd = CreateFile(dpath, oflags, + env->me_mfd = CreateFileA(dpath, oflags, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, len, mode | FILE_FLAG_WRITE_THROUGH, NULL); #else @@ -8981,7 +8981,7 @@ mdb_env_copy2(MDB_env *env, const char *path, unsigned int flags) * already in the OS cache. */ #ifdef _WIN32 - newfd = CreateFile(lpath, GENERIC_WRITE, 0, NULL, CREATE_NEW, + newfd = CreateFileA(lpath, GENERIC_WRITE, 0, NULL, CREATE_NEW, FILE_FLAG_NO_BUFFERING|FILE_FLAG_WRITE_THROUGH, NULL); #else newfd = open(lpath, O_WRONLY|O_CREAT|O_EXCL, 0666); -- 1.9.5.msysgit.0

1 0

(ITS#8068) MDB library patch: Using IsWindowsVersionOrGreater() instead of obsolete GetVersion()
by pmedvedev＠gmail.com 27 Feb '15

27 Feb '15

Full_Name: Pavel Medvedev Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.25.225.40) --- libraries/liblmdb/mdb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 65293f4..a54ce83 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -239,6 +239,7 @@ union semun { #endif #ifdef _WIN32 +#include <VersionHelpers.h> #define MDB_USE_HASH 1 #define MDB_PIDLOCK 0 #define THREAD_RET DWORD @@ -3998,8 +3999,7 @@ mdb_env_open2(MDB_env *env) #ifdef _WIN32 /* See if we should use QueryLimited */ - rc = GetVersion(); - if ((rc & 0xff) > 5) + if (IsWindowsVersionOrGreater(6, 0, 0)) env->me_pidquery = MDB_PROCESS_QUERY_LIMITED_INFORMATION; else env->me_pidquery = PROCESS_QUERY_INFORMATION; -- 1.9.5.msysgit.0

1 0

(ITS#8067) MDB library patch: Added ssize_t typedef for Visual C++
by pmedvedev＠gmail.com 27 Feb '15

27 Feb '15

Full_Name: Pavel Medvedev Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.25.225.40) --- libraries/liblmdb/mdb.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 984a5bd..65293f4 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c%%0 @@ -96,7 +96,13 @@ extern int cacheflush(char *addr, int nbytes, int cache); #include <stdlib.h> #include <string.h> #include <time.h> + +#ifdef _MSC_VER +#include <io.h> +typedef SSIZE_T ssize_t; +#else #include <unistd.h> +#endif % A #if defined(__sun) || defined(ANDROID) /* Most platforms have posix_memalign, older may only have memalign */

1 0

Re: (ITS#8066) mdb_load truncates long values when resizing buffer
by hyc＠symas.com 26 Feb '15

26 Feb '15

catwell(a)archlinux.us wrote: > Full_Name: Pierre Chapuis > Version: master > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.238.40.212) > > > Description: > > Starting from 2048, the first input line larger than any power of two N > is truncated to N-1. This results in truncated values in the database. Thanks for the report. Fixed now in mdb.master > > Explanation: > > In the code that resizes the input buffer, fgets() is used. > fgets(*, n, *) reads a maximum of n-1 characters and 0-terminates > the string. When the next chunk is read, the '\0' remains in the > string. Later, strlen() is used and the string is truncated. > > Proposed fix: > > A patch against the current OpenLDAP master llllows. > > --- > > libraries/liblmdb/mdb_load.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libraries/liblmdb/mdb_load.c b/libraries/liblmdb/mdb_load.c > index f626692..e86b6fd 100644 > --- a/libraries/liblmdb/mdb_load.c > +++ b/libraries/liblmdb/mdb_load.c > @@ -218,7 +218,7 @@ badend: > } > c1 = buf->mv_data; > c1 += buf->mv_size; > - if (fgets((char *)c1, buf->mv_size, stdin) == NULL) {D%D > + if (fgets((char *)c1-1, buf->mv_size+1, stdin) == NULL) { > Eof = 1; > badend(); > return EOF; > > --- > > > -- -- 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#8066) mdb_load truncates long values when resizing buffer
by catwell＠archlinux.us 26 Feb '15

26 Feb '15

For what it's worth, here is a slightly better patch. The previous one would start the strlen() one character too far. I don't think it would have much consequence in practice, but this should be safer. --- libraries/liblmdb/mdb_load.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libraries/liblmdb/mdb_load.c b/libraries/liblmdb/mdb_load.c index f626692..960d23d 100644 --- a/libraries/liblmdb/mdb_load.c +++ b/libraries/liblmdb/mdb_load.c @@ -216,9 +216,8 @@ badend: prog, lineno); return EOF; } - c1 = buf->mv_data; - c1 += buf->mv_size; - if (fgets((char *)c1, buf->mv_size, stdin) == NULL) { + c1 = buf->mv_data + buf->mv_size - 1; + if (fgets((char *)c1, buf->mv_size+1, stdin) == NULL) { Eof = 1; badend(); return EOF; -- Pierre Chapuis

1 0

(ITS#8066) mdb_load truncates long values when resizing buffer
by catwell＠archlinux.us 25 Feb '15

25 Feb '15

Full_Name: Pierre Chapuis Version: master OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.238.40.212) Description: Starting from 2048, the first input line larger than any power of two N is truncated to N-1. This results in truncated values in the database. Explanation: In the code that resizes the input buffer, fgets() is used. fgets(*, n, *) reads a maximum of n-1 characters and 0-terminates the string. When the next chunk is read, the '\0' remains in the string. Later, strlen() is used and the string is truncated. Proposed fix: A patch against the current OpenLDAP master llllows. --- libraries/liblmdb/mdb_load.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libraries/liblmdb/mdb_load.c b/libraries/liblmdb/mdb_load.c index f626692..e86b6fd 100644 --- a/libraries/liblmdb/mdb_load.c +++ b/libraries/liblmdb/mdb_load.c @@ -218,7 +218,7 @@ badend: } c1 = buf->mv_data; c1 += buf->mv_size; - if (fgets((char *)c1, buf->mv_size, stdin) == NULL) {D%D + if (fgets((char *)c1-1, buf->mv_size+1, stdin) == NULL) { Eof = 1; badend(); return EOF; ---

1 0

Re: (ITS#8064) SIGSEGV in monitor-shutdown code
by leo＠yuriev.ru 25 Feb '15

25 Feb '15

Yes, Howard you are right. In our CI-process 'make test' crashes only for 2.5 branch. I was noted 2.4 in the ITS, it's my mistake. To fix this bug seems a de-registration should be provided by monitor-backend. 2015-02-25 17:47 GMT+03:00 Howard Chu <hyc(a)symas.com>: > pierangelo.masarati(a)polimi.it wrote: >> >> back-monitor was designed before back-config, without considering the >> possibility of database removal during regular operations. There might >> be several flaws of that kind. > > > Removal is not supported in 2.4. All of that is work-in-progress for 2.5. > Patches welcome, but this is not a 2.4 bug. > > >> My suggestion is that back-monitor is never shut down (it should be >> inhibited) except at slapd shutdown. Meanwhile, the code initialization >> and shutdown could be redesigned to properly handle those cases. >> >> On 25/02/2015 15:18, leo(a)yuriev.ru wrote: >>> >>> Full_Name: Leonid Yuriev >>> Version: 2.4-HEAD >>> OS: RHEL7 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (31.130.36.33) >>> >>> >>> Monitor-backend shutdown code could call a callback from registered >>> subsystem >>> after it is already destroyed. >>> >>> For instance, currently ldap-backend frees its own registered context >>> (lmi_mss >>> from ldap_monitor_info_t) before than monitor_back_db_destroy() will be >>> called. >>> >>> Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend >>> database is configured and such freed context will be overwrited. >>> >>> This bug could be reproduced by a filling-memory-with-non-zero before >>> calling >>> free() from glibc. >>> >>> >>> >> >> > > > -- > -- 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

(ITS#8065) autogroup+accesslog problems
by hyc＠openldap.org 25 Feb '15

25 Feb '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (199.188.194.66) Submitted by: hyc The autogroup overlay doesn't work well with accesslog. This is the same problem we've had in the past with e.g. memberof, refint, and other overlays that do internal modifications as a side-effect of a main user operation. In particular, autogroup's internal ops use the same timestamp as the original op, so accesslog will log one of these internal ops and then none of the others because it uses the timestamp for the RDN of its log entries, and that RDN is already in use. This means the main user onevever gets logged, nor do any side-effect modifications after the first one. The solution in previous cases has been to turn off all accesslog activity for internal operations. In the case of accesslog used for replication, accesslog shoulononly log the main user operation, and it's up to replicas to perform the same internal operations themselves as needed.

1 0

Re: (ITS#8064) SIGSEGV in monitor-shutdown code
by hyc＠symas.com 25 Feb '15

25 Feb '15

pierangelo.masarati(a)polimi.it wrote: > back-monitor was designed before back-config, without considering the > possibility of database removal during regular operations. There might > be several flaws of that kind. Removal is not supported in 2.4. All of that is work-in-progress for 2.5. Patches welcome, but this is not a 2.4 bug. > My suggestion is that back-monitor is never shut down (it should be > inhibited) except at slapd shutdown. Meanwhile, the code initialization > and shutdown could be redesigned to properly handle those cases. > > On 25/02/2015 15:18, leo(a)yuriev.ru wrote: >> Full_Name: Leonid Yuriev >> Version: 2.4-HEAD >> OS: RHEL7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (31.130.36.33) >> >> >> Monitor-backend shutdown code could call a callback from registered subsystem >> after it is already destroyed. >> >> For instance, currently ldap-backend frees its own registered context (lmi_mss >> from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called. >> >> Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend >> database is configured and such freed context will be overwrited. >> >> This bug could be reproduced by a filling-memory-with-non-zero before calling >> free() from glibc. >> >> >> > > -- -- 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#8064) SIGSEGV in monitor-shutdown code
by pierangelo.masarati＠polimi.it 25 Feb '15

25 Feb '15

back-monitor was designed before back-config, without considering the possibility of database removal during regular operations. There might be several flaws of that kind. My suggestion is that back-monitor is never shut down (it should be inhibited) except at slapd shutdown. Meanwhile, the code initialization and shutdown could be redesigned to properly handle those cases. On 25/02/2015 15:18, leo(a)yuriev.ru wrote: > Full_Name: Leonid Yuriev > Version: 2.4-HEAD > OS: RHEL7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (31.130.36.33) > > > Monitor-backend shutdown code could call a callback from registered subsystem > after it is already destroyed. > > For instance, currently ldap-backend frees its own registered context (lmi_mss > from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called. > > Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend > database is configured and such freed context will be overwrited. > > This bug could be reproduced by a filling-memory-with-non-zero before calling > free() from glibc. > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2015