- openldap-bugs - openldap.org

Re: (ITS#7789) Unreliable mdb_env_set_mapsize()
by hyc＠symas.com 24 Jan '14

24 Jan '14

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: LMDB 0.9.11 > OS: Linux x86_64 > URL: > Submission from: (NULL) (129.240.6.254) > Submitted by: hallvard > > > Mapsize changes do not work as described, do not reliably store the > mapsize in the map, and it's hard to see how it is supposed to work. > E.g.: > - Open an environment twice, in processes X and Y. > - X grows the map and writes (commits) something to the DB. That > MDB_meta gets the new mapsize. > - Y writes to the DB. It does not get MDB_MAP_RESIZED like the doc > says, nor does it carry forward X's MDB_meta.mm_mapsize change. The doc says the caller of set_mapsize is required to make sure there are no active transactions when it is called. As such, X failed this requirement, and this sequence of events is explicitly unsupported. If Y doesn't start its write txn until after X finishes, then Y will see the new size. > - Process Z opens the environment without doing set_mapsize(), > and gets the original mapsize from the MDB_meta written by Y. > > For that matter, from reading the doc I'd expect a mapsize change to > commit a txn with the new mapsize. There's no mention that the change > (and the MDB_MAP_RESIZED) will wait for something to be committed. > > mdb_txn_commit() writes nothing if the txn didn't change anything. > It needs to notice that there is a mapsize change to write. > > The doc talks about shrinking the map, but reduced mapsizes are not > written to the datafile. Only increases are written. > > All in all, it looks to me like _changing_ the mapsize should be an > operation on a write transaction or invoke a write transaction, while > setting the size or catching up with a mapsize change can be an > environment operation. That way it would be possible to make sense of > it. A txn can do it when it has no cursors and no dirty WRITEMAP > pages (or WRITEMAP could spill all pages first). > > BTW, I don't see the point of conditionally avoiding to write the > mapsize in mdb_env_write_meta() when full page gets written to disk > anyway - as long as txn_begin() stashes the mapsize from the original > meta so it knows what to write. (It need not obey the mapsize at that > point, but it must carry a change forward.) > > -- -- 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#7790) config.h filename clash. include path broken.
by mark＠ibiblio.org 23 Jan '14

23 Jan '14

Full_Name: Mark Version: 2.4.35 OS: Solaris 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.63.89.15) openldap-2.4.35/servers/slapd/back-ldif root# cc -I/usr/local/include -I../../../include -I../../../include -I.. -I./.. -I/usr/local/include -c ldif.c -o ldif.o "ldif.c", line 166: warning: no explicit type given "ldif.c", line 166: syntax error before or at: ldifcfg This happens because there is a /usr/local/include/config.h from libstdc++ which is included before openldap-2.4.35/servers/slapd/config.h, according to the -I include path order. The Makefile sets CFLAGS to "AC_CFLAGS DEFS". DEFS includes XINCPATH which should precede AC_CFLAGS, not succeed it. Either the order needs to be fixed, or more usefully config.h renamed to slapd_config.h To have configure work correctly, CPPFLAGS needs to be set to "-I/usr/local/include" otherwise /usr/local/include isn't searched for db.h, it picks up /usr/include/db.h which is not the one it needs to link against. + print -r -- 'configure:20296: checking for Berkeley DB major version in db.h' [...] 1> conftest.c + /bin/ggrep -E __db_version + eval '$CPP $CPPFLAGS conftest.c' + cc -E conftest.c + set X __db_version 5 none none + ol_cv_bdb_major=5 You can see it's only using CPP and CPPFLAGS in the eval command. Not CFLAGS which has the path for the correct db.h to use. To fix that, CPPFLAGS also needs to point to /usr/local/include. I'm using these fixes to move past both problems and get a properly working build: ./configure --prefix=/usr/local \ --with-cyrus-sasl \ --enable-bdb=yes \ --enable-spasswd=yes \ --enable-modules \ --enable-wrappers \ --enable-shared \ --with-tls=openssl \ ol_cv_berkeley_db_version=4.8.30 mv servers/slapd/config.h servers/slapd/slapd_config.h perl -pe 's#config.h#slapd_config.h#' -i servers/slapd/*.c perl -pe 's#"config.h"#"slapd_config.h"#' -i servers/slapd/*/*.c gmake depend gmake

1 0

(ITS#7789) Unreliable mdb_env_set_mapsize()
by h.b.furuseth＠usit.uio.no 22 Jan '14

22 Jan '14

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.11 OS: Linux x86_64 URL: Submission from: (NULL) (129.240.6.254) Submitted by: hallvard Mapsize changes do not work as described, do not reliably store the mapsize in the map, and it's hard to see how it is supposed to work. E.g.: - Open an environment twice, in processes X and Y. - X grows the map and writes (commits) something to the DB. That MDB_meta gets the new mapsize. - Y writes to the DB. It does not get MDB_MAP_RESIZED like the doc says, nor does it carry forward X's MDB_meta.mm_mapsize change. - Process Z opens the environment without doing set_mapsize(), and gets the original mapsize from the MDB_meta written by Y. For that matter, from reading the doc I'd expect a mapsize change to commit a txn with the new mapsize. There's no mention that the change (and the MDB_MAP_RESIZED) will wait for something to be committed. mdb_txn_commit() writes nothing if the txn didn't change anything. It needs to notice that there is a mapsize change to write. The doc talks about shrinking the map, but reduced mapsizes are not written to the datafile. Only increases are written. All in all, it looks to me like _changing_ the mapsize should be an operation on a write transaction or invoke a write transaction, while setting the size or catching up with a mapsize change can be an environment operation. That way it would be possible to make sense of it. A txn can do it when it has no cursors and no dirty WRITEMAP pages (or WRITEMAP could spill all pages first). BTW, I don't see the point of conditionally avoiding to write the mapsize in mdb_env_write_meta() when full page gets written to disk anyway - as long as txn_begin() stashes the mapsize from the original meta so it knows what to write. (It need not obey the mapsize at that point, but it must carry a change forward.)

1 0

(ITS#7788) pwdFailureTime and pwdChangedTime registered in user entry even if no ppolicy associated with the entry
by coudot＠linagora.com 16 Jan '14

16 Jan '14

Full_Name: Clement OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) Hi, I have configured a ppolicy overlay without olcPPolicyDefault value. So I use pwdPolicySubentry in user entries to bind them to their policy configuration entry. Overlay ppolicy is compiled in slapd, not as module. I use LTB package. If I create an account without pwdPolicySubentry, the attributes pwdChangedTime and pwdFailureTime are generated for this entry. And as the entry is never locked (which is a normal behavior, fixed in http://www.openldap.org/its/index.cgi?findid=6168), the number of values in pwdFailureTime can grow indefinitely. IMHO, no ppolicy operational attributes should be present in an entry not linked to a password policy.

1 0

Re: (ITS#7787) Authentication success if password is expired and password must be changed
by coudot＠linagora.com 16 Jan '14

16 Jan '14

Le 16/01/2014 16:42, Howard Chu a écrit : > coudot(a)linagora.com wrote: >> >> >> Le 16/01/2014 15:31, Howard Chu a écrit : >>> coudot(a)linagora.com wrote: >>>> Full_Name: Clement OUDOT >>>> Version: 2.4.38 >>>> OS: GNU/Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (83.145.72.122) >>>> >>>> >>>> Here is the situation : a user account is >>>> 1/ expired (the password age is more that the one configured in >>>> pwdMaxGae) >>>> 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy >>>> configuration >>>> object is TRUE) >>>> >>>> In this case, when doing a BIND, the result code is 0: >>>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret >>>> -e >>>> ppolicy >>>> ldap_bind: Success (0); Password must be changed (Password expires >>>> in >>>> 0 >>>> seconds) >>>> dn: uid=coudot,ou=users,dc=example,dc=com >>>> >>>> If I remove pwdReset attribute, then: >>>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret >>>> -e >>>> ppolicy >>>> ldap_bind: Invalid Credentials (49); Password expired >>>> >>>> According to password policy draft, the password must change flag >>>> should not >>>> affect the BIND result code. >>> >>> The draft specifies the policy checks in the order in which they are >>> to be performed. The PasswordMustBeChanged check occurs before the >>> PasswordExpired check. >>> >>> The code works as designed. >> >> >> Well, I understand. If this is not a bug in the OpenLDAP >> implementation, it is maybe a point to discuss in the draft. Indeed, >> a >> simple LDAP client (that don't use ppolicy control) will get a >> successful BIND response even if the password is expired. > > How can the password be expired if the admin has just reset it? > I never said it was *just* reset, we can imagine the password was reset a year ago and that the user never changed it. What I point here is that a reset password never expires, whatever you configure in pwdMaxAge. People using the password reset feature must be aware of this, and be sure to have an application that will force the user to change its password. >> Maybe it is the wanted behavior, maybe not. > >> The fact is that if an administator reset the password (by changing >> password value and setting pwdReset to TRUE), this reseted password >> will >> never expire. From my point of view, this is a security flaw in the >> password policy system, as a lot of applications just use the BIND >> operation on LDAP server (searches and other operations are done by >> application LDAP accounts). > > I agree that the MustChange feature doesn't mesh well with > applications that simply perform a Bind and then do nothing else. Feel > free to raise this point on the ldapext mailing list. Yes I will give a try. You can close this ITS, thanks for the answers. Clement.

1 0

Re: (ITS#7787) Authentication success if password is expired and password must be changed
by hyc＠symas.com 16 Jan '14

16 Jan '14

coudot(a)linagora.com wrote: > > > Le 16/01/2014 15:31, Howard Chu a écrit : >> coudot(a)linagora.com wrote: >>> Full_Name: Clement OUDOT >>> Version: 2.4.38 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.145.72.122) >>> >>> >>> Here is the situation : a user account is >>> 1/ expired (the password age is more that the one configured in >>> pwdMaxGae) >>> 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy >>> configuration >>> object is TRUE) >>> >>> In this case, when doing a BIND, the result code is 0: >>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e >>> ppolicy >>> ldap_bind: Success (0); Password must be changed (Password expires in >>> 0 >>> seconds) >>> dn: uid=coudot,ou=users,dc=example,dc=com >>> >>> If I remove pwdReset attribute, then: >>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e >>> ppolicy >>> ldap_bind: Invalid Credentials (49); Password expired >>> >>> According to password policy draft, the password must change flag >>> should not >>> affect the BIND result code. >> >> The draft specifies the policy checks in the order in which they are >> to be performed. The PasswordMustBeChanged check occurs before the >> PasswordExpired check. >> >> The code works as designed. > > > Well, I understand. If this is not a bug in the OpenLDAP > implementation, it is maybe a point to discuss in the draft. Indeed, a > simple LDAP client (that don't use ppolicy control) will get a > successful BIND response even if the password is expired. How can the password be expired if the admin has just reset it? > Maybe it is the wanted behavior, maybe not. > The fact is that if an administator reset the password (by changing > password value and setting pwdReset to TRUE), this reseted password will > never expire. From my point of view, this is a security flaw in the > password policy system, as a lot of applications just use the BIND > operation on LDAP server (searches and other operations are done by > application LDAP accounts). I agree that the MustChange feature doesn't mesh well with applications that simply perform a Bind and then do nothing else. Feel free to raise this point on the ldapext mailing list. -- -- 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#7787) Authentication success if password is expired and password must be changed
by coudot＠linagora.com 16 Jan '14

16 Jan '14

Le 16/01/2014 15:31, Howard Chu a écrit : > coudot(a)linagora.com wrote: >> Full_Name: Clement OUDOT >> Version: 2.4.38 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.145.72.122) >> >> >> Here is the situation : a user account is >> 1/ expired (the password age is more that the one configured in >> pwdMaxGae) >> 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy >> configuration >> object is TRUE) >> >> In this case, when doing a BIND, the result code is 0: >> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e >> ppolicy >> ldap_bind: Success (0); Password must be changed (Password expires in >> 0 >> seconds) >> dn: uid=coudot,ou=users,dc=example,dc=com >> >> If I remove pwdReset attribute, then: >> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e >> ppolicy >> ldap_bind: Invalid Credentials (49); Password expired >> >> According to password policy draft, the password must change flag >> should not >> affect the BIND result code. > > The draft specifies the policy checks in the order in which they are > to be performed. The PasswordMustBeChanged check occurs before the > PasswordExpired check. > > The code works as designed. Well, I understand. If this is not a bug in the OpenLDAP implementation, it is maybe a point to discuss in the draft. Indeed, a simple LDAP client (that don't use ppolicy control) will get a successful BIND response even if the password is expired. Maybe it is the wanted behavior, maybe not. The fact is that if an administator reset the password (by changing password value and setting pwdReset to TRUE), this reseted password will never expire. From my point of view, this is a security flaw in the password policy system, as a lot of applications just use the BIND operation on LDAP server (searches and other operations are done by application LDAP accounts). Clément.

1 0

Re: (ITS#7787) Authentication success if password is expired and password must be changed
by hyc＠symas.com 16 Jan '14

16 Jan '14

coudot(a)linagora.com wrote: > Full_Name: Clement OUDOT > Version: 2.4.38 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.145.72.122) > > > Here is the situation : a user account is > 1/ expired (the password age is more that the one configured in pwdMaxGae) > 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy configuration > object is TRUE) > > In this case, when doing a BIND, the result code is 0: > $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy > ldap_bind: Success (0); Password must be changed (Password expires in 0 > seconds) > dn: uid=coudot,ou=users,dc=example,dc=com > > If I remove pwdReset attribute, then: > $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy > ldap_bind: Invalid Credentials (49); Password expired > > According to password policy draft, the password must change flag should not > affect the BIND result code. The draft specifies the policy checks in the order in which they are to be performed. The PasswordMustBeChanged check occurs before the PasswordExpired check. The code works as designed. -- -- 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#7787) Authentication success if password is expired and password must be changed
by coudot＠linagora.com 16 Jan '14

16 Jan '14

Full_Name: Clement OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) Here is the situation : a user account is 1/ expired (the password age is more that the one configured in pwdMaxGae) 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy configuration object is TRUE) In this case, when doing a BIND, the result code is 0: $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy ldap_bind: Success (0); Password must be changed (Password expires in 0 seconds) dn: uid=coudot,ou=users,dc=example,dc=com If I remove pwdReset attribute, then: $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy ldap_bind: Invalid Credentials (49); Password expired According to password policy draft, the password must change flag should not affect the BIND result code.

1 0

Re: (ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by hyc＠symas.com 15 Jan '14

15 Jan '14

pierangelo.masarati(a)polimi.it wrote: > On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote: >> Full_Name: Raphael Ouazana >> Version: 2.4.38 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.173.78.196) >> >> >> Hi, >> >> I have an old configuration that I would like to export/reimport. The >> olcDbDirectory item of this configuration contains a directory that does not >> longer exist. >> It it then impossible to modify the parameter: >> - I was told not to edit directly LDIF config files >> - if i try a slapcat -n0 I get: >> 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory >> 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory: >> value #0: invalid path: No such file or directory >> slapcat: bad configuration directory! >> >> I think slapcat should always allow to export a configuration. > > I see the point; slapcat is failing because to export the configuration > (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first, > and it reads the whole config tree. > > Perhaps when slapcat of only the config database is requested, config > parsing should skip other databases, or at least ignore errors, if possible. Agreed, we definitely need this. > > p. > > -- -- 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#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by pierangelo.masarati＠polimi.it 15 Jan '14

15 Jan '14

On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote: > Full_Name: Raphael Ouazana > Version: 2.4.38 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > Hi, > > I have an old configuration that I would like to export/reimport. The > olcDbDirectory item of this configuration contains a directory that does not > longer exist. > It it then impossible to modify the parameter: > - I was told not to edit directly LDIF config files > - if i try a slapcat -n0 I get: > 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory > 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory: > value #0: invalid path: No such file or directory > slapcat: bad configuration directory! > > I think slapcat should always allow to export a configuration. I see the point; slapcat is failing because to export the configuration (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first, and it reads the whole config tree. Perhaps when slapcat of only the config database is requested, config parsing should skip other databases, or at least ignore errors, if possible. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by raphael.ouazana＠linagora.com 15 Jan '14

15 Jan '14

Full_Name: Raphael Ouazana Version: 2.4.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) Hi, I have an old configuration that I would like to export/reimport. The olcDbDirectory item of this configuration contains a directory that does not longer exist. It it then impossible to modify the parameter: - I was told not to edit directly LDIF config files - if i try a slapcat -n0 I get: 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory: value #0: invalid path: No such file or directory slapcat: bad configuration directory! I think slapcat should always allow to export a configuration. Regards, Raphaël Ouazana.

1 0

Re: (ITS#7785) ContextCSN not updated
by michael＠stroeder.com 14 Jan '14

14 Jan '14

badguy9588(a)hotmail.com wrote: > Full_Name: > Version: 2.4.11 > OS: Redhat Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.82.28.193) > > > We are using 4 ways multimaster openldap 2.4.11 for more than 5 years. > > On Jan 3, 2014, one of the openldap contextCSN is not updated, always stay at > Jan 3 01:xx:xx, all the other servers are already updated to Jan 6. Any reason why you insist on using such an ancient release? In 5,5 years since 2.4.11 release there have been numerous important contextCSN related fixes to OpenLDAP 2.4.x code. You should definitely upgrade! Everything else is wasting your own time and the OpenLDAP project people's resources. Ciao, Michael.

1 0

(ITS#7785) ContextCSN not updated
by badguy9588＠hotmail.com 14 Jan '14

14 Jan '14

Full_Name: Version: 2.4.11 OS: Redhat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.82.28.193) We are using 4 ways multimaster openldap 2.4.11 for more than 5 years. On Jan 3, 2014, one of the openldap contextCSN is not updated, always stay at Jan 3 01:xx:xx, all the other servers are already updated to Jan 6. So, this introduce large amount of sync data between the 4 openldap servers finally, cause the slapd process memory increase from 500mb to 4Gb and finally, all memory used up and all 4 servers hanged and error message in KVM shows "Kernel panic, out of memory". The servers needed to reboot in order to resume access. However, after some time, it will happen again. We finally find that the contextCSN in one server is not updated. What we do is stop the slapd process in that server, delete the data files and the do a backup in other 3 servers. Then restore the backup in the problem server from the backup using slapadd and finally, all the data is synced. What's the root cause of this problem ? We have been using it for over 5 years already and this is the first time that this problem occurs. Thanks

1 0

Re: (ITS#7784) Client stores bindpw in cleartext
by fumiyas＠osstech.co.jp 14 Jan '14

14 Jan '14

At Tue, 14 Jan 2014 01:12:55 GMT, ylau(a)huawei.com wrote: > When nss_ldap uses LDAP authentication with binding method, the bindpw stored in > ldap.conf is clear text. > However on Solaris NS_LDAP_BINDPASSWD could be stored in encrypted string. There > is no password obfuscation with nss_ldap. > So we considered it is a security issue and will affect the result of security > audit. {NS1} format is not safe. You can decrypt it without any other secret. http://stuff.iain.cx/2008/05/03/ns103eb2365be169abbe3a45088a10a/ -- -- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/ -- PGP Fingerprint: BBE1 A1C9 525A 292E 6729 CDEC ADC2 9DCA 5E1C CBCA

1 0

Re: (ITS#7784) Client stores bindpw in cleartext
by hyc＠symas.com 14 Jan '14

14 Jan '14

ylau(a)huawei.com wrote: > Full_Name: Yo Lau > Version: 2.3.32 > OS: SUSE Linux Enterprise Server 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.130.146.228) > OpenLDAP 2.3.32 is over 6 years old and long since unsupported. nss_ldap is not a piece of OpenLDAP software. Contact SuSE for support, this ITS will be closed. > When nss_ldap uses LDAP authentication with binding method, the bindpw stored in > ldap.conf is clear text. > However on Solaris NS_LDAP_BINDPASSWD could be stored in encrypted string. There > is no password obfuscation with nss_ldap. > So we considered it is a security issue and will affect the result of security > audit. > > -- -- 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#7784) Client stores bindpw in cleartext
by ylau＠huawei.com 14 Jan '14

14 Jan '14

Full_Name: Yo Lau Version: 2.3.32 OS: SUSE Linux Enterprise Server 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.130.146.228) When nss_ldap uses LDAP authentication with binding method, the bindpw stored in ldap.conf is clear text. However on Solaris NS_LDAP_BINDPASSWD could be stored in encrypted string. There is no password obfuscation with nss_ldap. So we considered it is a security issue and will affect the result of security audit.

1 0

Re: (ITS#7778) Index and derived attribute bug
by hyc＠symas.com 13 Jan '14

13 Jan '14

yann.cezard(a)univ-pau.fr wrote: > Full_Name: Yann Cezard > Version: 2.4.38 > OS: Debian GNU/Linux Wheezy / amd64 > URL: ftp://ftp.openldap.org/incoming/Yann-Cezard-130109.tgz > Submission from: (NULL) (2001:660:6701:14:225:64ff:fe92:685b) > > > Hello, > > I hit a bug with the latest version of OpenLDAP (2.4.38) that was not present, > at least in 2.4.17 (made a test on an older server that we were using before I > discovered this). > This happens on both lmdb and bdb backend (as we were using BDB before upgrading > to 2.4.38, I tested with both on 2.4.38 to ensure that the problem was not LMDB > related). > The only ways to make the '(mail=*)' filter matches again the modified entry, is > to modify the mail attribute, or to run slapindex. > If you remove the index on the mail attribute, then there is no such problem. > It only happens when deleting all/the last derived attributes (supannAutreMail > here) from the entry. > > Sounds to me like a bug, isn't it ? Thanks for the report, fixed now in git master. > > Regards. > > -- -- 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#7783) tlsm_ctx_free crashes if ctx->tc_pin_file is null
by hyc＠symas.com 12 Jan '14

12 Jan '14

chris.w.martin(a)oracle.com wrote: > Full_Name: Chris Martin > Version: 2.4.23-32.el6_4.1 but also present in git repository version > OS: Oracle Linux 6 > URL: > Submission from: (NULL) (148.87.19.206) > > > If tlsm_ctx_free is entered with ctx->tc_pin_file null it will crash when it > calls PL_strfree with that null pointer. > > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… > 2039 static void > 2040 tlsm_ctx_free ( tls_ctx *ctx ) > 2041 { > ... > 2069 PL_strfree( c->tc_pin_file ) > > I propose that an "if ( c->tc_pin_file )" be added before this line to protect > against this. > > > The specific use case when we hit this involves automount calling openldap > ldap_start_tls_s which fails with LDAP_CONNECT_ERROR. automount then calls > openldap ldap_unbind_ext which calls ldap_ld_free which calls > ldap_int_tls_destroy which triggers this crash above. Thanks for the report. This is now fixed in git master, plus another potential instance of the same issue. You guys are crazy to even be using this MozNSS POS. -- -- 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#7778) Index and derived attribute bug
by quanah＠zimbra.com 11 Jan '14

11 Jan '14

--On Thursday, January 09, 2014 2:55 PM +0000 yann.cezard(a)univ-pau.fr wrote: > Full_Name: Yann Cezard > Version: 2.4.38 > OS: Debian GNU/Linux Wheezy / amd64 > URL: ftp://ftp.openldap.org/incoming/Yann-Cezard-130109.tgz > Submission from: (NULL) (2001:660:6701:14:225:64ff:fe92:685b) > > > Hello, > > I hit a bug with the latest version of OpenLDAP (2.4.38) that was not > present, at least in 2.4.17 (made a test on an older server that we were > using before I discovered this). > This happens on both lmdb and bdb backend (as we were using BDB before > upgrading to 2.4.38, I tested with both on 2.4.38 to ensure that the > problem was not LMDB related). <hbf> ITS#7778: Broken in 2.4.37 by 96f35c08944a "ITS#7329 optimize index update for simple add". -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7783) tlsm_ctx_free crashes if ctx->tc_pin_file is null
by chris.w.martin＠oracle.com 10 Jan '14

10 Jan '14

Full_Name: Chris Martin Version: 2.4.23-32.el6_4.1 but also present in git repository version OS: Oracle Linux 6 URL: Submission from: (NULL) (148.87.19.206) If tlsm_ctx_free is entered with ctx->tc_pin_file null it will crash when it calls PL_strfree with that null pointer. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… 2039 static void 2040 tlsm_ctx_free ( tls_ctx *ctx ) 2041 { ... 2069 PL_strfree( c->tc_pin_file ) I propose that an "if ( c->tc_pin_file )" be added before this line to protect against this. The specific use case when we hit this involves automount calling openldap ldap_start_tls_s which fails with LDAP_CONNECT_ERROR. automount then calls openldap ldap_unbind_ext which calls ldap_ld_free which calls ldap_int_tls_destroy which triggers this crash above.

1 0

Re: AW: (ITS#7249) slapd segfault with memberof overlay on frontend db
by michael＠stroeder.com 10 Jan '14

10 Jan '14

harald.winkelmann(a)bertschinnovation.com wrote: >> Why do you report issues for a release which is almost two years old without trying to reproduce it with a current release before? > > This is the actual openldap version distributed with the actual debian stable version (wheezy). Whatever Debian considers "stable" (for what definition?) is not relevant for OpenLDAP. Personally I consider the Debian packages rather unmaintained. Ciao, Michael.

1 0

AW: (ITS#7249) slapd segfault with memberof overlay on frontend db
by harald.winkelmann＠bertschinnovation.com 10 Jan '14

10 Jan '14

>Why do you report issues for a release which is almost two years old without trying to reproduce it with a current release before? This is the actual openldap version distributed with the actual debian stable version (wheezy). I just made a full dist-upgrade and run into this problem. This thread is still active. So... Harry

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by michael＠stroeder.com 10 Jan '14

10 Jan '14

harald.winkelmann(a)bertschinnovation.com wrote: > Debian Wheezy > openldap_2.4.31 Why do you report issues for a release which is almost two years old without trying to reproduce it with a current release before? Ciao, Michael.

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by harald.winkelmann＠bertschinnovation.com 10 Jan '14

10 Jan '14

--_000_30c408c19b944a1a837b407b026fe1afAMSPR01MB050eurprd01pro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, is anybody working on this issue? I've the same problem. I tried the following patch and it works for me. Why isn't it applied here. https://bugs.archlinux.org/task/38137?getfile=3D11329 Debian Wheezy openldap_2.4.31 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none modulepath /usr/lib/ldap moduleload back_bdb moduleload memberof.la overlay memberof ####################################################################### # Specific Backend Directives for @BACKEND@: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend bdb With friendly regards Harald Winkelmann Software Development DAM Group GmbH Planckstra=DFe 7 88677 Markdorf --_000_30c408c19b944a1a837b407b026fe1afAMSPR01MB050eurprd01pro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"DE" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hello,<o:p></o:p> <o:p> </o:p> is anybody working on this issu= e?<o:p></o:p> I’ve the same problem.<o:= p></o:p> I tried the following patch and= it works for me. Why isn’t it applied here.<o:p></o:p> <a href=3D"https://bugs.archlin= ux.org/task/38137?getfile=3D11329">https://bugs.archlinux.org/task/38137?ge= tfile=3D11329</a><o:p></o:p> <o:p> </o:p> Debian Wheezy<o:p></o:p>= openldap_2.4.31<o:p></o:p></spa= n> <o:p> </o:p> # Schema and objectClass defini= tions<o:p></o:p> include    =      /etc/ldap/schema/core.schema<o:p></o:p> include    =      /etc/ldap/schema/cosine.schema<o:p></o:p></= p> include       &nb= sp; /etc/ldap/schema/nis.schema<o:p></o:p> include       &nb= sp; /etc/ldap/schema/inetorgperson.schema<o:p></o:p> <o:p> </o:p> pidfile    =      /var/run/slapd/slapd.pid<o:p></o:p> argsfile   &nbsp= ;    /var/run/slapd/slapd.args<o:p></o:p> loglevel   &nbsp= ;    none<o:p></o:p> <o:p> </o:p> modulepath   &nb= sp;  /usr/lib/ldap<o:p></o:p> moduleload   &nb= sp;  back_bdb<o:p></o:p> moduleload   &nb= sp;  memberof.la<o:p></o:p> overlay memberof<o:p></o:p></sp= an> <o:p> </o:p> ###############################= ########################################<o:p></o:p> # Specific Backend Directives f= or @BACKEND@:<o:p></o:p> # Backend specific directives a= pply to this backend until another<o:p></o:p> # 'backend' directive occurs<o:= p></o:p> backend    =      bdb<o:p></o:p> <o:p> </o:p> <o:p> </o:p> With friendly regards<o:p></o:p></= span> Harald Winkelmann<o:p></o:p></span= > Software Development<o:p></o:p></s= pan> <o:p> </o:p> DAM Group GmbH<o:p></o:p= > Planckstra=DFe 7<o:p></o:p> 88677 Markdorf<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_30c408c19b944a1a837b407b026fe1afAMSPR01MB050eurprd01pro_--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs