openldap-bugs July 2015

openldap-bugs@openldap.org

24 participants
75 discussions

Re: (ITS#8188) unable to see the users on client after importing the TLS certificate
by quanah＠zimbra.com 08 Jul '15

08 Jul '15

--On Friday, July 03, 2015 2:53 PM +0000 vijeshkrishna(a)yahoo.com wrote: > Full_Name: Vijesh > Version: 2.4 > OS: RHEL 6.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.219.201.69) > > > Hello Team, Hello, The ITS system is for reporting bugs, not asking usage questions. Please direct your questions to the openldap-technical(a)openldap.org email list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8192) liblmdb confuses Windows error code with errno values
by h.b.furuseth＠usit.uio.no 08 Jul '15

08 Jul '15

Typo in original report: > #define MDB_FILE_NEW (MDB_LAST_ERRCODE + 9) > (above instead of MDB_NO_ROOT for easier cherry-picking.) "above instead of below MDB_NO_ROOT". On 08/07/15 22:36, Howard Chu wrote: > When there is a platform-specific error code that describes the > situation, we should use it. In particular, if the error code comes from > an underlying system call and accurately describes that failure, we > should pass it through. Yes. I only meant to talk about where mdb.c explicitly picks errno codes, like it does with EIO/ENOSPC. (And where it compares codes from system calls with errno codes.) > If the failure is LMDB-specific, and not related > to any particular system call, then we should define an MDB_* code for it.

1 0

Re: (ITS#8192) liblmdb confuses Windows error code with errno values
by hyc＠symas.com 08 Jul '15

08 Jul '15

h.b.furuseth(a)usit.uio.no wrote: > On 08/07/15 20:29, h.b.furuseth(a)usit.uio.no wrote: >> Finally, I suggest we replace the explicit EIO/ENOSPC returns >> with either a new MDB code or #define MDB_EIO EIO on Unix >> and something else on Windows. > > I mean, without waiting for LMDB-1.*. They are fairly > obscure errors, I doubt anyone is testing for them. When there is a platform-specific error code that describes the situation, we should use it. In particular, if the error code comes from an underlying system call and accurately describes that failure, we should pass it through. If the failure is LMDB-specific, and not related to any particular system call, then we should define an MDB_* code for it. -- -- 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#8192) liblmdb confuses Windows error code with errno values
by h.b.furuseth＠usit.uio.no 08 Jul '15

08 Jul '15

On 08/07/15 20:29, h.b.furuseth(a)usit.uio.no wrote: > Finally, I suggest we replace the explicit EIO/ENOSPC returns > with either a new MDB code or #define MDB_EIO EIO on Unix > and something else on Windows. I mean, without waiting for LMDB-1.*. They are fairly obscure errors, I doubt anyone is testing for them.

1 0

(ITS#8192) liblmdb confuses Windows error code with errno values
by h.b.furuseth＠usit.uio.no 08 Jul '15

08 Jul '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: Windows 7 with cygwin URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_env_write_meta() loops to retry_write if ErrCode() == EINTR. That's ERROR_TOO_MANY_OPEN_FILES = 4 on Windows. New in 0.9.15. == This one is older, in mdb_env_setup_locks(). Also wrong on Windows: rc = ErrCode(); if (rc && rc != EACCES && rc != EAGAIN) I don't know what that code is doing. I think that belongs under if ((rc = mdb_env_excl_lock(env, excl))) goto fail; where it would read as if (*excl <= 0 && (rc = ErrCode()) && rc != EACCES && rc != EAGAIN) ==D%D ENOENT confusion: mdb_env_read_header() can explicitly return ENOENT, but only as an internal code. So mdb_strerror() should drop ENOENT. We can rename/renumber it to avoid confusion: /* Internal result codes, not exposed outside liblmdb */ #define MDB_FILE_NEW (MDB_LAST_ERRCODE + 9) (above instead of MDB_NO_ROOT for easier cherry-picking.) OTOH lmdb.h lists "ENOENT - the directory specified by the path parameter doesn't exist." That's not related to the above. It should be "ENOENT (Unix) or ERROR_PATH_NOT_FOUND (Windows) - ..." Or maybe the doc for this code should say something more general, or simply be omitted. I found the Windows code by testing @ Windows. Reading Windows doc did not help. == Finally, I suggest we replace the explicit EIO/ENOSPC returns with either a new MDB code or #define MDB_EIO EIO on Unix and something else on Windows. (I think ENOSPC should be EIO too, there could be other reasons for a short write.) Then we can drop those from mdb_strerror() too.

1 0

Re: (ITS#8191) mdb_txn_commit(empty txn) does not sync
by h.b.furuseth＠usit.uio.no 07 Jul '15

07 Jul '15

On 07/07/15 21:44, h.b.furuseth(a)usit.uio.no wrote: > My feeling is that this is a quirk the user should not need to > know about, and it's cleaner to sy r rather than to document it. ...cleaner to sync rather than...

1 0

(ITS#8191) mdb_txn_commit(empty txn) does not sync
by h.b.furuseth＠usit.uio.no 07 Jul '15

07 Jul '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_txn_commit(txn which made no changes) does not mdb_env_sync(), but lmdb.h says several times that Commit flushes buffers to disk. My feeling is that this is a quirk the user should not need to know about, and it's cleaner to sy r rather than to document it. OTOH I don't know if "fast commit of no-change txns" is a feature which someone expects to work, and if sync can be expensive even when there is no new data to flush. (I don't know what BDB does.)

1 0

(ITS#8190) LMDB cursor bug
by hyc＠openldap.org 07 Jul '15

07 Jul '15

Full_Name: Howard Chu Version: LMDB 0.9.15 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.234.0) Submitted by: hyc In mdb_cursor_set(SET_RANGE) a call to mdb_cursor_sibling is used if the matching key wasn't found on the current page. If this call fails, the EOF flag should be set on the cursor but isn't. Subsequent attempts to call mdb_cursor_next() will read garbage data. A fix is coming shortly.

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 06 Jul '15

06 Jul '15

On 07/06/2015 01:30 PM, Michael Ströder wrote: > Consider that you are under on-going attack with many different > accounts affected by the lockout treshold. Then you cannot simply wait > for pwdFailureCountInterval seconds because your system is changing > all the time. > > Such a situation is a real world scenario. Ok -- I'm probably not understanding enough about your particular scenario to fully appreciate the concerns that you express. But I think there could be ways to address them in this enhancement -- for instance, by adding optional parameter(s) like ppolicy_purge_failures <nfailures> and/or ppolicy_purge_olderthan <timestamp>, which could then be configured to accommodate the scenario you describe. At this point, I'll think I'll leave it up to the OpenLDAP developers as to how they want to proceed on this, and/or to ask for more information. Thanks for the discussion Michael. Regards, -Kartik

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by michael＠stroeder.com 06 Jul '15

06 Jul '15

Kartik Subbarao wrote: > On 07/06/2015 12:25 PM, Michael Str=C3=B6der wrote: >> Hmm, still have some doubts: If you want to raise the failure count li= mit >> later you would automatically unlock some accounts you don't want to u= nlock >> at this particular point in time. >=20 > Two thoughts on this: >=20 > 1) If you raise the failure count limit, aren't you inherently making a= > decision to be more lenient in your policy, and thereby accepting that = some > accounts are not going to be locked out as fast as they might be under = the > previous policy? Yes, there could be a situation where you want to deliberately relax the lockout policy after carefully considering various security aspects of yo= ur particular deployment. > It seems to me that any "inadvertent" unlocking due to purged > pwdFailureTime values could be embraced under this general umbrella of = leniency. No! You set a new lockout limit and most people would expect this to be s= olely effective on user accounts which did not reach the new limit yet. > 2) If pwdFailureCountInterval is set to some reasonably low number, the= n this > whole concern becomes moot: Just wait for pwdFailureCountInterval secon= ds > after you decide to change the configuration, before actually changing = the > configuration :-) Consider that you are under on-going attack with many different accounts affected by the lockout treshold. Then you cannot simply wait for pwdFailureCountInterval seconds because your system is changing all the t= ime. Such a situation is a real world scenario. =3D> @OpenLDAP developers: leave as is! Ciao, Michael. P.S.: I'm not a big fan of password lockout anyway because it's misconfig= ured too often because of brain-dead comapny security policies.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2015