- openldap-bugs - openldap.org

Re: (ITS#8621) Unique through multiple attribute
by michael＠stroeder.com 19 Mar '17

19 Mar '17

tatarenko(a)alpha-it.ru wrote: > When use Unique overlay it is not possible to prevent users from inserting value > in attributeA (like otherMailbox) that is already was used in attributeB (like > mail) through whole domain. > If i put multiple attributes to Unique overlay it still search through one > attribute. > If i use > olcUniqueURI: ldap:///dc=instatsport,dc=com?mail,otherMailbox,proxyAddresses?sub > Unique overlay still make this search for mail: > unique_search (|(mail=123(a)example.com)) > And this search for otherMailbox > unique_search (|(otherMailbox=123(a)example.com)) I'd say it works as designed and there is no bug. The work-around for your use-case is to use SUP to derive from a common attribute type. But this should be discussed on openldap-technical mailing list. Ciao, Michael.

1 0

(ITS#8621) Unique through multiple attribute
by tatarenko＠alpha-it.ru 18 Mar '17

18 Mar '17

Full_Name: Tatarenko Vasily Version: 2.4.44 OS: Freebsd 11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.74.103.57) When use Unique overlay it is not possible to prevent users from inserting value in attributeA (like otherMailbox) that is already was used in attributeB (like mail) through whole domain. If i put multiple attributes to Unique overlay it still search through one attribute. If i use olcUniqueURI: ldap:///dc=instatsport,dc=com?mail,otherMailbox,proxyAddresses?sub Unique overlay still make this search for mail: unique_search (|(mail=123(a)example.com)) And this search for otherMailbox unique_search (|(otherMailbox=123(a)example.com))

1 0

Re: (ITS#8620) GCC error undeclared PTHREAD_MUTEX_ROBUST
by blissend＠gmail.com 18 Mar '17

18 Mar '17

--94eb2c184874dd3bec054af90cab Content-Type: text/plain; charset=UTF-8 Ahah, it compiles if you remove lines 277-279 which was... #if defined(MDB_OWNERDEAD) && (MDB_USE_ROBUST) #define MDB_ROBUST_SUPPORTED 1 #endif However, I'm not sure that's what one should do. --94eb2c184874dd3bec054af90cab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Ahah, it compiles if you remove lines 277-279 which was...= <div><br></div><div><div>#if defined(MDB_OWNERDEAD) && (MDB_USE_ROB= UST)</div><div>#define MDB_ROBUST_SUPPORTED<span class=3D"gmail-Apple-tab-s= pan" style=3D"white-space:pre"> </span>1</div><div>#endif</div></div><div><= br></div><div>However, I'm not sure that's what one should do.</div= ></div> --94eb2c184874dd3bec054af90cab--

1 0

(ITS#8620) GCC error undeclared PTHREAD_MUTEX_ROBUST
by blissend＠gmail.com 18 Mar '17

18 Mar '17

Full_Name: Adam Carlin Version: lmdb 0.9.20 OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.27.217.230) I'm using Windows 10 with msys2 64bit (http://www.msys2.org/) which utilizes mingw-w64. When I compile lmdb (https://github.com/LMDB/lmdb/tree/mdb.RE/0.9) v0.9.20 it spits out the error message below... blissend@shockedloris MSYS /c/Compile/lmdb/libraries/liblmdb $ make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb.c mdb.c: In function mdb_env_setup_locks: mdb.c:4853:17: warning: implicit declaration of function pthread_mutexattr_setrobust [-Wimplicit-function-declaration] if (!rc) rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ mdb.c:4853:53: error: PTHREAD_MUTEX_ROBUST undeclared (first use in this function) if (!rc) rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST); ^~~~~~~~~~~~~~~~~~~~ mdb.c:4853:53: note: each undeclared identifier is reported only once for each function it appears in mdb.c: In function mdb_mutex_failed: mdb.c:362:37: warning: implicit declaration of function pthread_mutex_consistent [-Wimplicit-function-declaration] #define mdb_mutex_consistent(mutex) pthread_mutex_consistent(mutex) ^ mdb.c:10220:10: note: in expansion of macro mdb_mutex_consistent rc2 = mdb_mutex_consistent(mutex); ^~~~~~~~~~~~~~~~~~~~ make: *** [Makefile:83: mdb.o] Error 1 Anyway to fix this? If this helps, I've noticed that line 4853 for above error has an if check for MDB_ROBUST_SUPPORTED which gets defined on line 278. However the missing declaration of pthread_mutexattr_setrobust is in another if check above line 278.

1 0

Re: (ITS#8506) Authentication issue in ldap client machine after successfully integrating ldap in freenas OS
by quanah＠symas.com 18 Mar '17

18 Mar '17

Hello, There is no evidence of a bug with OpenLDAP based on your report. The OpenLDAP ITS is for bug reports. Usage/configuration questions such as this report should be directed to the OpenLDAP Technical mailing list. <http://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. --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#8614) Test suite fails when using --with-threads=no
by quanah＠symas.com 18 Mar '17

18 Mar '17

--On Friday, March 10, 2017 9:43 PM +0000 bwright(a)intacct.com wrote: > If you plan on retaining --with-threads=no feature, someone might want to > update the test suite to properly test LDAP when threads are disabled. Or > alternatively, inform the user that 'make test' doesn't support testing > LDAP when threads are disabled. Thanks for the report and great suggestion. --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#8500) typo in slapo-ppolicy(5)
by quanah＠symas.com 17 Mar '17

17 Mar '17

--On Monday, September 12, 2016 3:39 PM +0000 michael(a)stroeder.com wrote: Thanks for the report. This was fixed as part of the work on ITS#8185. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8619) Enhancement request: Nested group support using dynlist recursion
by christ.klinge＠web.de 17 Mar '17

17 Mar '17

Full_Name: Christopher Klinge Version: 2.4.44 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.193.142.51) As of right now, dynlist can be used to expand one level of nesting: overlay dynlist dynlist-attrset parentGroup childGroup dn: cn=Parent Group,ou=Groups,dc=example,dc=com objectClass: parentGroup cn: Parent Group childGroupURL: ldap:///cn=Child Group,ou=Groups,dc=example,dc=com?member?sub? dn: cn=Child Group,ou=Groups,dc=example,dc=com objectClass: childGroup cn: Child Group member: cn=User A,ou=People,dc=example,dc=com member: cn=User B,ou=People,dc=example,dc=com member: cn=User B,ou=People,dc=example,dc=com Querying the parent group will return: dn: cn=Parent Group,ou=Groups,dc=example,dc=com objectClass: parentGroup cn: Parent Group childGroupURL: ldap:///cn=Child Group,ou=Groups,dc=example,dc=com?member?sub? member: cn=User A,ou=People,dc=example,dc=com member: cn=User B,ou=People,dc=example,dc=com member: cn=User C,ou=People,dc=example,dc=com If cn=Child Group were to be a parent group itself, no further expansion would take place. I propose enabling dynlist recursion and adding a new configuration directive: dynlist-rec-attrset <group-oc> [<URI>] <URL-ad> <rec-ad> [[<mapped-ad>:]<member-ad>] Except for rec-ad, all parameters behave exactly like those of dynlist-attrset. The attribute rec-ad is mandatory. It is a comma separated list of attributes for which dynlist recursion is enabled. By adding a new directive, backwards compatibility is guaranteed. I suggest using a depth counter to prevent infinite loops. A configurable threshold with a fairly small default value is both light weight and sufficiently rigorous. Logging a suitable warning message upon reaching the threshold would inform the administrator about possible loops.

1 0

Re: (ITS#8465) ldapsearch & slapcat : different output
by quanah＠symas.com 17 Mar '17

17 Mar '17

--On Friday, July 15, 2016 4:15 PM +0000 norbert.massa(a)yopmail.com wrote: > Full_Name: Norbert MASSA > Version: 2.4.40 > OS: CentOS 7.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.240.254.57) Hi Norbert, There's virtually nothing to go on in this bug report. I.e. no configuration information, etc. What backend were you using (bdb? hdb? mdb?) etc. I'd also note that the ldapsearch you provided would not give a complete backup (It's missing dumps of the operational attributes). --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#8470) LastBind Module Issue
by quanah＠symas.com 17 Mar '17

17 Mar '17

--On Thursday, July 28, 2016 12:59 PM +0000 avijeett007(a)gmail.com wrote: Hello, This does not sound like a report for a bug in the OpenLDAP Software. OpenLDAP does not distribute startup scripts. I would suggest following up with your OS provider, since running slapd manually works as expected. Regards, 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#8477) OpenLDAP.org has a broken TLS certificate
by quanah＠symas.com 17 Mar '17

17 Mar '17

--On Thursday, August 11, 2016 5:53 AM +0000 demiobenour(a)gmail.com wrote: > Also, why the self-signed certificate at all? ??Let's Encrypt is > providing free certificates. This should now be fixed. --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#8617) Seg-fault while using meta database and rwm overlay together
by quanah＠symas.com 17 Mar '17

17 Mar '17

--On Wednesday, March 15, 2017 11:51 PM +0000 jaroslaw.wencel(a)gmail.com wrote: > Full_Name: Jaroslaw Wencel > Version: 2.4.42 > OS: Ubuntu 16.04.1 > URL: > Submission from: (NULL) (46.227.243.233) > > > Hi > > I'm trying to develop configuration which includes Active Directory > catalogue into main LDAP tree I have in my configuration. Everything > works well while using slapd-meta as long as I do not try to combine it > with rwm overlay. > > LDAP crashes while invoking modrdn change (refer to attached > crashme.ldif) with the configuration as in config.ldif. > > modrdn change works well until I add dn: > olcOverlay={0}rwm,olcDatabase={1}meta,cn=config to the configuration. > > I'm using OpenLDAP 2.4.42 installed from Ubuntu repositories (latest > version from 16.04.01). > I have uploaded > ftp://ftp.openldap.org/incoming/Jaroslaw-Wencel-170315.tgz to the ftp > server, archive file contains: > - config.ldif - dump of ldap configuration from the moment modrdn > operation crashes the server > - crashme.ldif - the ldif file I'm using for invoking modrdn operation > - crash.logs - slapd daemon log > > Please let me know if you have any further questions Hi, Thanks for the report! There are a number of known existing issues with slapo-rwm, so the detail provided here is quite useful. Regards, 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#8615) Dovecot can't connect to openldap over starttls
by quanah＠symas.com 16 Mar '17

16 Mar '17

--On Saturday, March 11, 2017 11:55 AM +0000 info(a)gwarband.de wrote: > Full_Name: Tobias Warband > Version: 2.4.40+dfsg-1+deb8u2 > OS: Debian 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (149.172.171.148) > > > Hello, > > I'm trying to configure dovecot with ldapconnection over starttls (Secure > LDAP). > I belief the problem is something with the methode ldap_start_tls_s() > or ldap_int_tls_connect() that's called from the first. > Other software can connect to the openldapserver e.g. postfix, > openxchange, apache. > All logs and configs are in the URL below. Hi Tobias, The ITS system is for reporting bugs in OpenLDAP. Nothing in this report indicates a bug with OpenLDAP. In fact the information you provide about other processes being able to connect to OpenLDAP without inssue further indicate no bug with OpenLDAP. Generally, I would advise you seek support from the Dovecot authors, as it is their product that is having issues, and they should be able to provide accurate and detailed information on how to properly configure their software to interface with LDAP. Alternatively, you may wish to try the openldap-technical list if discussing with the Dovecot community does not resolve the problem. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8618) ldapsearch - unexpected behavior with "-h URI -p PORT"
by alex＠r42.ch 16 Mar '17

16 Mar '17

Full_Name: Alexandre Rosenberg Version: 2.4.44 OS: Linux - CentOS7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.30.6.137) I found some unexpected behavior when using both '-h' and '-p' option with ldapserach. == Reproduce: - Use the '-h' option with an invalid hostname such as a URI - Also set a (valid) port using the '-p' option == Result: If those condition are met, ldapearch seem to always connect to localhost on port 389 $ ldapsearch -x -d 255 -h ldap://localhost -p 10389 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 == Expected behavior: Failure due to invalid hostname == Note: This *only* happens when both '-h' and '-p' are used. When only '-h' is used, following happens which seem fine: $ ldapsearch -x -d 255 -h ldap://localhost ldap_create ldap_url_parse_ext(ldap://ldap:%2F%2Flocalhost) ldap_err2string Could not create LDAP session handle for URI=ldap://ldap: %2F%2Flocalhost (-9): Bad parameter to an ldap routine == Additional example: Bellow are some more example - note adding "/" to the hostname is enough to trigger the issue. 1. $ ldapsearch -x -d 255 -h example.org -p 10636 -> Connects to example.org on port 10636 (as expected) 2. $ ldapsearch -x -d 255 -h /example.org -p 10636 -> Connects to localhost on port 389 (!) - note the added "/" 3. $ ldapsearch -x -d 255 -h /example.org Running the command will give you the debug output (which I omitted here). Note I am using openldap 2.4.44.

1 0

(ITS#8617) Seg-fault while using meta database and rwm overlay together
by jaroslaw.wencel＠gmail.com 15 Mar '17

15 Mar '17

Full_Name: Jaroslaw Wencel Version: 2.4.42 OS: Ubuntu 16.04.1 URL: Submission from: (NULL) (46.227.243.233) Hi I'm trying to develop configuration which includes Active Directory catalogue into main LDAP tree I have in my configuration. Everything works well while using slapd-meta as long as I do not try to combine it with rwm overlay. LDAP crashes while invoking modrdn change (refer to attached crashme.ldif) with the configuration as in config.ldif. modrdn change works well until I add dn: olcOverlay={0}rwm,olcDatabase={1}meta,cn=config to the configuration. I'm using OpenLDAP 2.4.42 installed from Ubuntu repositories (latest version from 16.04.01). I have uploaded ftp://ftp.openldap.org/incoming/Jaroslaw-Wencel-170315.tgz to the ftp server, archive file contains: - config.ldif - dump of ldap configuration from the moment modrdn operation crashes the server - crashme.ldif - the ldif file I'm using for invoking modrdn operation - crash.logs - slapd daemon log Please let me know if you have any further questions Thanks Jaroslaw Wencel

1 0

(ITS#8616) olcSpNopresent and olcSpReloadHint can't be modified dynamically
by elecharny＠symas.com 14 Mar '17

14 Mar '17

Full_Name: Emmanuel Lecharny Version: 2.4.44 OS: CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.246.56.212) Adding either the olcSpNoPresent/olcSpReloadHint into a syncprov overlay is possible using slapd.d. It the values are set to TRUE, you can remove them. If you set them to FALSE, trying to remove the value get you an error 80. Second thing : set the value to TRUE (works), then change it to FALSE (works). Now, you are stuck : you can't revert it to TRUE or remove them. Third thing : set the value to FALSE (works), then you can't change it to TRUE or delete the attribute. There is no other way that modifyin the ldif file to get it back on its feet.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 13 Mar '17

13 Mar '17

--On Monday, March 13, 2017 12:55 PM -0400 Matthew Berg <mberg(a)synacor.com> = wrote: > "After investigating the server setup, there are a few problems here. > The new server was being configured with sid=3D001 which was already > assigned to=C2=A0the original master. That's clearly going to screw = things > up." I'm aware of what Howard's original response was. That has nothing to do=20 with what the problem was, or the later 100% reproducible test I provided=20 him that did not have that problem. --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#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 13 Mar '17

13 Mar '17

"After investigating the server setup, there are a few problems here. The new server was being configured with sid=001 which was already assigned to the original master. That's clearly going to screw things up." On Mon, 2017-03-06 at 10:03 -0800, Quanah Gibson-Mount wrote: > --On Monday, March 06, 2017 5:24 PM +0000 mberg(a)synacor.com wrote: > > > Reading back over the report on ITS-8281, the reported behavior > > would have been a collision of generating a new contextCSN as well > > as duplicating the producer's SID. So it's generated contextCSN > > would have masked the one it never committed from the original > > master. > > I'm not sure what you mean by duplicating the producer's SID. Both > nodes > had unique SID values. There were no duplicated SIDs. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by > OpenLDAP: > <http://www.symas.com> > -- Matthew Berg <mberg(a)synacor.com> This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

(ITS#8615) Dovecot can't connect to openldap over starttls
by info＠gwarband.de 11 Mar '17

11 Mar '17

Full_Name: Tobias Warband Version: 2.4.40+dfsg-1+deb8u2 OS: Debian 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (149.172.171.148) Hello, I'm trying to configure dovecot with ldapconnection over starttls (Secure LDAP). I belief the problem is something with the methode ldap_start_tls_s() or ldap_int_tls_connect() that's called from the first. Other software can connect to the openldapserver e.g. postfix, openxchange, apache. All logs and configs are in the URL below. https://gwarband.de/openldap/dovecot.log https://gwarband.de/openldap/dovecot-ldap.conf https://gwarband.de/openldap/openldap.log https://gwarband.de/openldap/trace.dump Greetings Tobias

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 11 Mar '17

11 Mar '17

> From: Ond=F8ej Kuzn=EDk > Sent: Thursday, March 9, 2017 5:32 AM >=20 > Is that something that you can replicate reliably? Would you be able = to > share the configuration (especially overlays)? Unfortunately it is not deterministically reproducible, it just randomly happens occasionally. I haven't noticed anything in particular that = seems to be a pattern or in common on each occurrence. I will shoot you a copy of = my configuration directly. > Based on the traces I've taken while testing, I haven't seen anything > suspicious that the perl library would generate, but if you have the > packets or slapd ber dumps, they might help confirm this for your case > as well. I haven't been able to get a packet capture or leave debugging on long enough to catch it since the crash is so sporadic and it only occurs on = a production system at widely interspersed intervals :(. Thanks for looking at it.

1 0

(ITS#8614) Test suite fails when using --with-threads=no
by bwright＠intacct.com 10 Mar '17

10 Mar '17

Full_Name: Brian Wright Version: 2.4.44 OS: CentOS 6.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.136.225.254) When configuring and compiling OpenLDAP using --with-threads=no flag, the test suite fails to complete. It seems the test suite appears to be dependent on threads for a successful run. Unfortunately, this test suite issue makes it difficult to know if LDAP is functioning correctly when compiled without threads. Reproduce this by using the following: ./configure --with-threads=no make depend make make test Note, all backends fail at least one test when threads are disabled. For example, if you set --enable-bdb=no --enable-hdb=no and leave only --enable-mdb=yes, mdb itself fails the test suite. The same for bdb and hdb if they are the only backends available. If you plan on retaining --with-threads=no feature, someone might want to update the test suite to properly test LDAP when threads are disabled. Or alternatively, inform the user that 'make test' doesn't support testing LDAP when threads are disabled.

1 0

Re: (ITS#8613) slapo-memberOf documentation update (Unsafe to use with replication)
by quanah＠symas.com 09 Mar '17

09 Mar '17

--On Thursday, March 09, 2017 12:54 AM +0000 quanah(a)openldap.org wrote: > It is possible to set up slapo-dynlist to operate as a replacement for > slapo-memberOf, and it is safe in a replicated environment. The tricky > part of using slapo-dynlist is that membership information must be > maintained by updating user objects rather than by updating group > objects, which may be difficult for end users depending on how they > perform group management. It's also possible to do this in the reverse direction. I.e., normal static groups that will populate memberOf in the user entry. To do this, you have to hack the dyngroup schema, changing groupOfURLs from STRUCTURAL to AUXILIARY. In the slapd config, the dynlist config looks like: dynlist-attrset groupOfUrls memberURL memberOf Then we can create some groups: root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com "cn=testgroup" dn: cn=testgroup,ou=Group,dc=example,dc=com objectClass: groupOfNames cn: testgroup member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com "cn=alttestgroup" dn: cn=alttestgroup,ou=Group,dc=example,dc=com objectClass: groupOfNames cn: alttestgroup member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com The user entry looks like: root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com "cn=Marice McCaugherty" objectClass memberOf memberURL dn: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: groupOfURLs memberURL: ldap:///dc=example,dc=com??sub?(member=cn=Marice McCaugherty,ou=Pro duct Testing,dc=example,dc=com) memberOf: cn=testgroup,ou=Group,dc=example,dc=com memberOf: cn=alttestgroup,ou=Group,dc=example,dc=com Doing it this way means that people currently using memberOf wouldn't need to change how group management is done. --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#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 09 Mar '17

09 Mar '17

Hi Paul, I've tried to reproduce the issue you're seeing, setting up deltasync replication and trying to send various combinations of modifies to the master. However, none of that has crashed either the server receiving the modification, nor the other servers it replicated to. No change either when the second server has to replicate directly off the accesslog database without the benefit of syncprov's sessionlog. Is that something that you can replicate reliably? Would you be able to share the configuration (especially overlays)? Based on the traces I've taken while testing, I haven't seen anything suspicious that the perl library would generate, but if you have the packets or slapd ber dumps, they might help confirm this for your case as well. Regards, Ondrej

1 0

Re: (ITS#8613) slapo-memberOf documentation update (Unsafe to use with replication)
by michael＠stroeder.com 09 Mar '17

09 Mar '17

quanah(a)openldap.org wrote: > root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H > ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com cn=testgroup > dn: cn=testgroup,ou=Group,dc=example,dc=com > objectClass: groupOfURLs > cn: testgroup > memberURL: ldap:///dc=example,dc=com??sub?(memberOf=cn=testgroup,ou=Group,dc=e > xample,dc=com) > member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com For this particular use-case it would be nice if memberURL could automagically reference the group entry itself. Something similar to the set syntax: memberURL: ldap:///dc=example,dc=com??sub?(memberOf=*this/entryDN*) Well, a simple plugin class in web2ldap will also do... :-) Ciao, Michael.

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 09 Mar '17

09 Mar '17

The code making the update is in perl, using Net::LDAP, and looks like: $entry->replace(eduPersonAffiliation => \@eduPersonAffiliation); For the case of the crash, the array @eduPersonAffiliation is empty, effectively deleting the attribute. I'm not 100% sure what this generates on the wire, I'd have to debug it. I can say it's the same code that's been running for a decade or so with no issues. The schema that defines the attribute is available at: https://spaces.internet2.edu/display/macedir/OpenLDAP+eduPerson

1 0

(ITS#8613) slapo-memberOf documentation update (Unsafe to use with replication)
by quanah＠openldap.org 09 Mar '17

09 Mar '17

Full_Name: Quanah Gibson-Mount Version: 2.3 and higher OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The slapo-memberOf overlay is not safe to use in a replicated environment due to the way in which replication occurs. In particular, slapo-memberOf works fine as long as all user objects are created before any group objects. As soon as there are user objects that are members of a group where the user object was created after the group, breakage will occur if any consumer falls back into REFRESH mode. This is particularly trivial to reproduce by simply setting up a new empty consumer and allowing it to populate via REFRESH. This limitation should be clearly noted in the man page and the admin guide documentation. It is possible to set up slapo-dynlist to operate as a replacement for slapo-memberOf, and it is safe in a replicated environment. The tricky part of using slapo-dynlist is that membership information must be maintained by updating user objects rather than by updating group objects, which may be difficult for end users depending on how they perform group management. Example configuration: .... include "/opt/symas/etc/openldap/schema/memberof.schema" include "/opt/symas/etc/openldap/schema/dyngroup.schema" .... moduleload dynlist.la .... database mdb .... index memberOf ... overlay dynlist dynlist-attrset groupOfUrls memberURL member Then in the database: dn: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com objectClass: memberOfOC memberOf: cn=testgroup,ou=Group,dc=example,dc=com root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com cn=testgroup dn: cn=testgroup,ou=Group,dc=example,dc=com objectClass: groupOfURLs cn: testgroup memberURL: ldap:///dc=example,dc=com??sub?(memberOf=cn=testgroup,ou=Group,dc=e xample,dc=com) member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com The memberOf schema I came up with on the fly. It would need a different OID for the objectClass, and possibly a different objectClass name, as I stole those from ppolicy for testing purposes: attributetype ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' ) objectclass ( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'memberOfOC' SUP top AUXILIARY MUST ( memberOf ) )

1 0

(ITS#8612) lmdb build fails on illumos / solaris
by lorban＠bitronix.be 06 Mar '17

06 Mar '17

Full_Name: Ludovic Orban Version: OS: OmniOS r151020 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:a03f:1cdc:c300:384b:af79:f57c:b134) Building lmdb on illumos fails with the following error: mdb.c: In function 'mdb_env_copythr': mdb.c:9036:6: error: too many arguments to function 'sigwait' sigwait(&set, &tmp); ^ In file included from mdb.c:132:0: /usr/include/signal.h:165:12: note: declared here extern int sigwait(sigset_t *); ^ This happens because to use sigwait on illumos, you have to add the -D_POSIX_PTHREAD_SEMANTICS switch to the compiler. Changing the Makefile THREADS line to add the switch solves the problem: THREADS = -pthread -D_POSIX_PTHREAD_SEMANTICS FYI, I haven't tested on sun/oracle solaris but I guess it suffers from the exact same problem.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 06 Mar '17

06 Mar '17

--On Monday, March 06, 2017 5:24 PM +0000 mberg(a)synacor.com wrote: > Reading back over the report on ITS-8281, the reported behavior would > have been a collision of generating a new contextCSN as well as > duplicating the producer's SID. So it's generated contextCSN would > have masked the one it never committed from the original master. I'm not sure what you mean by duplicating the producer's SID. Both nodes had unique SID values. There were no duplicated SIDs. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8611) Option to block SSL renegotation after X attempts
by quanah＠openldap.org 06 Mar '17

06 Mar '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) Using SSL renegotiation is a common form of DoS attack against services. It should be possible to configure the max # of times a client can request the server renegotiate the SSL layer before being dropped. Alternatively, an option to completely disable SSL renegotiation in the slapd configuration may also be desirable.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 06 Mar '17

06 Mar '17

Reading back over the report on ITS-8281, the reported behavior would have been a collision of generating a new contextCSN as well as duplicating the producer's SID. So it's generated contextCSN would have masked the one it never committed from the original master. However, the point still stands that the contextCSN entry is *not* being written to the access log by the first server (A) here. It is only being written by the second server (B). So in the scenario that is supposed to be addressed by the fix - a second MMR node with an uninitialized database is in its initial refresh, it wouldn't be receiving contextCSN updates through the access log because they simply aren't there. To me the logical behaviour would be that a new node would remain without a recorded contextCSN until it receives the sync cookie along with the refreshDone message. Sending an explicit contextCSN update after every single accesslog entry seems an awfully expensive and unintuitive approach to fixing a refresh issue. TL;DR: The objection raised in scenario #3 stands if you are initializing a new MMR node, since. Or in a single master + replica scenario. Or to rephrase, if these entries are intended and necessary, shouldn't they be generated on the original server as well? This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

(ITS#8610) ldaps not usable with DNS SRV
by Silvio.Wanka＠fiege.com 06 Mar '17

06 Mar '17

Full_Name: Silvio Wanka Version: openldap-client-2.4.44 OS: FreeBSD 10.3-RELEASE-p16 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.138.118.158) Hi, if I use "ldap:///dc%3Dexample%2Cdc%3Dorg" on a test system all works properly but I must use LDAPS on a DMZ system and so I try "ldaps:///dc%3Dexample%2Cdc%3Dorg" but this search for a ldap DNS SRV record which of course returns the normal ldap port not the ldaps port. This can't work, because a firewall is between. Is this normal (by design) or an bug? There is also an old discussion on your site: http://www.openldap.org/lists/openldap-technical/201203/msg00027.html. IMO should OpenSSL either support DNS SRV lookup for each scheme or for none. TIA, Silvio

1 0

(ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 05 Mar '17

05 Mar '17

Full_Name: Paul B. Henson Version: 2.4.44 + ITS 8432 patch OS: Linux (Gentoo) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (96.251.22.157) As discussed in: https://www.openldap.org/lists/openldap-technical/201702/msg00077.html I'm getting random segfaults with openldap 2.4.44 (with the ITS 8432 patch applied) with the following backtrace: (gdb) bt full #0 0x0000000000485c61 in modify_add_values (e=e@entry=0x7f50727fb480, mod=mod@entry=0x7f50600019a0, permissive=0, text=text@entry=0x7f50727fb9a0, textbuf=textbuf@entry=0x7f50727fb4d0 "modify/delete: eduPersonAffiliation: n o such attribute", textlen=textlen@entry=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/mods.c:61 rc = <optimized out> op = 0x4fe045 "add" a = <optimized out> pmod = {sm_desc = <optimized out>, sm_values = 0x0, sm_nvalues = 0x0, sm _numvals = <optimized out>, sm_op = <optimized out>, sm_flags = <optimized out>, sm_type = {bv_len = <optimized out>, bv_val = <optimized out>}} __PRETTY_FUNCTION__ = "modify_add_values" #1 0x00007f526dfccd0c in mdb_modify_internal (op=op@entry=0x7f50727fc600, tid=tid@entry=0x1088a90, modlist=0x7f5060001960, e=e@entry=0x7f50727fb480, text=text@entry=0x7f50727f b9a0, textbuf=textbuf@entry=0x7f50727fb4d0 "modify/delete: eduPersonAffiliation: n o such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/back-mdb/mod ify.c:137 rc = <optimized out> err = <optimized out> mod = 0x7f50600019a0 ml = 0x7f50600019a0 save_attrs = 0x7f5060004270 ap = 0x7f5272f53010 glue_attr_delete = <optimized out> got_delete = 0 __PRETTY_FUNCTION__ = "mdb_modify_internal" #2 0x00007f526dfce134 in mdb_modify (op=0x7f50727fc600, rs=0x7f50727fb980) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/back-mdb/mod ify.c:624 mdb = 0x7f5272f53010 e = 0x7f5060004220 manageDSAit = <optimized out> textbuf = "modify/delete: eduPersonAffiliation: no such attribute\000\37 7\037\000\000\000\000\000\000\000@\003\315\000\000\000\000\000\200\271\177rP\177 \000\000\021\000\000\000\000\000\000\000.,\020`P\177\000\000 \360o\315\000\000\000\000\000\360\002\315\000\000\000\000\000\037\000\000\000\00 0\000\000\000\000\306\177rP\17 7\000\000\300\064\000`P\177\000\000\000\000\000\000\000\000\000\000\360o\315\000 \000\000\000\000 T\315\000\000 \000\000\000\000\306\177rP\177\000\000\270\232N\000\000\000\000\000 l\315\000\000\000\000\000\350\064\000`P\17 7\000\000\000\306\177rP\177\000\000\000\000\000\000\000\000\000\000"... txn = 0x1088a90 opinfo = {moi_oe = {oe_next = {sle_next = 0x7f50727fb930}, oe_key = 0x7f 5272f53010}, moi_txn = 0x1088a90, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f50727fb430 dummy = {e_id = 66196, e_name = {bv_len = 40, bv_val = 0x7f50600041e8 "uid=aapriest,ou=user,dc=csupomona,dc=edu"}, e_nname = {bv_len = 40, bv_val = 0x7f5060004d18 "uid=aapriest,ou=user,dc=csupomona,dc=edu"}, e_attrs = 0xd202e8, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7f50 60004220} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7f50727fb250} num_ctrls = 0 numads = 55 #3 0x000000000049c2ea in overlay_op_walk (op=op@entry=0x7f50727fc600, rs=0x7f50727fb980, which=op_modify, oi=0xcd6a40, on=<optimized out>) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/backover.c:6 77 func = <optimized out> rc = <optimized out> #4 0x000000000049c441 in over_op_func (op=0x7f50727fc600, rs=<optimized out>, which=<optimized out>) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/backover.c:7 30 oi = <optimized out> on = <optimized out> be = 0xcd0ac0 db = {bd_info = 0x7f526e1e6d40 <bi>, bd_self = 0xcd0ac0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\0 01\000\000\001", '\000' <repea ts 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, ss s_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 64}, be_s uffix = 0xcd0880, be_nsuffix = 0xca5c90, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_sc hemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 31, bv_val = 0xcd02f0 "cn=ldapr oot,dc=csupomona,dc=edu"}, be_rootndn = {bv_len = 31, bv_val = 0xcd0340 "cn=ldaproot,dc=csupomona ,dc=edu"}, be_rootpw = { bv_len = 38, bv_val = 0xca49a0 "{SSHA}XXXXXXXXXXXXXXXXXXXXXXX"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0xca5840, be_acl = 0xcd1c80, be_dfltaccess = ACL_READ, be_ extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_p ending_csn_list = 0xf85dc0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nuse rs = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}} , __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0xcd 75c0, be_pb = 0x0, be_cf_ocs = 0x7f526e1e68c0 <mdbocs>, be_private = 0x7f5272f53010, be_n ext = {stqe_next = 0x0}} cb = {sc_next = 0x7f50727fb950, sc_response = 0x49b650 <over_back_respon se>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0xcd6a40} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #5 0x000000000048d938 in syncrepl_message_to_op (si=si@entry=0xcd8520, op=op@entry=0x7f50727fc600, msg=0x7f5060102940) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/syncrepl.c:2 394 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x48cd60 <syncrepl_mes sage_to_op>}, oe_si = 0xcd8520} ber = 0x7f50604b5390 modlist = 0x7f5060496f60 ls = 0x778940 <accesslog_sc> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_mat ched = 0x0, sr_text = 0x7f50727fb4d0 "modify/delete: eduPersonAffiliation: no such attribute", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0 , r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasld ata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x7f5060003490, sc_response = 0x48c8d0 <null_callback>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x0} text = 0x0 txtbuf = "@\277\177rP\177\000\000\020\274\177rP\177\000\000X\371P\000\00 0\000\000\000\266P\246rR\177\0 00\000@\277\177rP\177\000\000X\371P\000\000\000\000\000\240\272\177rP\177\000\00 0\060\275\246rR\177\000\000X\3 71P\000\000\000\000\000@^\246rR\177\000\000\000\000\000\000\000\000\000\000\002\ 000\000\000P\177\000\000\020\0 00\000\000\000\000\000\000\260\272\177rP\177\000\000\377\377\377\377\377\377\377 \377&\000\000\017\000\000\000\ 000\020\t\020\230P\177\000\000x\215I`P\177\000\000\177\215I`P\177\000\000\000\27 5\177rP\177\000\000p\234\305\0 00\000\000\000\000@\275\177rP\177\000\000 \205\315\000\000\000\000\000\313\343I\000\000\000\000\000\020", '\00 0' <repeats 23 times>... bdn = {bv_len = 40, bv_val = 0x7f50600013ac "uid=aapriest,ou=user,dc=csu pomona,dc=edu"} dn = {bv_len = 40, bv_val = 0x7f5060001c48 "\360!"} ndn = {bv_len = 40, bv_val = 0x7f5060001cd8 "\340\034"} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0x7f506049fb80 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #6 0x00000000004915d7 in do_syncrep2 (op=op@entry=0x7f50727fc600, si=si@entry=0xcd8520) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/syncrepl.c:1 013 match = <optimized out> syncUUID = {{bv_len = 16, bv_val = 0x7f506049fb47 "~\373\337l\214\335IȻ\346\230\350\r\n", <inc omplete sequence \316>}, { bv_len = 0, bv_val = 0x0}} cookie = {bv_len = 15, bv_val = 0x7f506049fb59 "rid=003,sid=003"} rctrls = 0x7f506049abe0 rctrlp = <optimized out> bdn = {bv_len = 44, bv_val = 0x7f506000135a "reqStart=20161225113103.000 003Z,cn=accesslog"} si_tag = <optimized out> entry = <optimized out> punlock = -1 syncstate = 1 retdata = 0x0 retoid = 0x78 <error: Cannot access memory at address 0x78> syncUUIDs = 0x0 len = 15 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "@\373I`P\177\000\ 000h\373I`P\177\000\000h\373I` P\177", '\000' <repeats 26 times>, "п\177rP\177\000\000\000\000\000\000R\177\000\000\001\000\000\000\000\000\0 00\000dZ\023qR\177\000\000Dh,\200\207\001\305\345\000\000\000\000\001\000\000\00 0\200\255J`P\177\000\000`\305\ 177rP\177\000\000\257X\244qR\177\000\000\031p-rR\177\000\000\000\000\000\000\000 \000\000\000\b\246\246rR\177\0 00\000\060", '\000' <repeats 15 times>, "\001\000\000\000\000\000\000\000d"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e- 319, palign = 0x10002 <error: Cannot access memory at address 0x10002>} ber = 0x7f50727fbf40 msg = 0x7f5060102940 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 3, octet_str = {bv_len = 15, bv_val = 0x7f5060498d70 "rid=003,sid=003"}, sid = 3, sc_next = {stqe _next = 0x0}} syncCookie_req = {ctxcsn = 0x7f50604a6c10, sids = 0x7f50604996c0, numcsn s = 4, rid = 3, octet_str = { bv_len = 183, bv_val = 0x7f50604984e0 "rid=003,sid=000,csn=20161225102351.582901Z# 000000#000#000000;201612130230 51.387118Z#000000#001#000000;20160721062752.989665Z#000000#002#000000;2016072106 2824.859874Z#000000#003#000000 "}, sid = 0, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 11 tout_p = 0x7f50727fbc00 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" #7 0x0000000000495793 in do_syncrepl (ctx=ctx@entry=0x7f50727fcb90, arg=arg@entry=0xcd8a00) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/syncrepl.c:1 564 rtask = 0xcd8a00 si = 0xcd8520 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INV ALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __cou nt = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__ prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_star ttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = { bv_len = 0, bv_val = 0x503e42 ""}, c_peer_name = {bv_len = 0, bv_val = 0x503e42 ""}, c_listener = 0x506e00 <dummy_list>, c_sasl_bind_mech = {bv_len = 0, bv _val = 0x0}, c_sasl_dn = { bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0 x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, s ai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protoco l = 0, c_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x 0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nu sers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}} , __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__d ata = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, _ _mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nu sers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}} , __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__d ata = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, _ _mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_i n_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_udp = 0 '\000', c_is_tls = 0 '\000', c_ needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0 , c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x 0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n _get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0 x0, c_send_ldap_result = 0x442d90 <slap_send_ldap_result>, c_send_search_entry = 0x4437d0 <slap_send_search_entry>, c_send_search_reference = 0x444d10 <slap_send_search_reference>, c_send_ldap_extended = 0x4434a0 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x443640 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f50727fc770, o_tag = 102, o_time = 14826654 63, o_tincr = 13, o_bd = 0x7f50727fb690, o_req_dn = {bv_len = 40, bv_val = 0x7f506049f2c0 "uid=aapriest,ou=user,dc=csupomona,dc=edu" }, o_req_ndn = {bv_len = 40, bv_val = 0x7f506049f300 "uid=aapriest,ou=user,dc=csupomona,dc=edu" }, o_request = {oq_add = { rs_modlist = 0x7f5060001960, rs_e = 0x1}, oq_bind = {rb_method = 1610619232, rb_cred = { bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0} , rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x7f5060001 960}, oq_modify = { rs_mods = {rs_modlist = 0x7f5060001960, rs_no_opattrs = 1 '\001' }, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7f5060001960, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_ nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 1610619232, rs_deref = 32592, rs_slimit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_ val = 0x0}}, oq_abandon = { rs_msgid = 1610619232}, oq_cancel = {rs_msgid = 1610619232}, oq_ extended = {rs_reqoid = { bv_len = 139983184730464, bv_val = 0x1 <error: Cannot access m emory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs _reqoid = { bv_len = 139983184730464, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000 ', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_ subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 t imes>, o_controls = 0x7f50727fc8c0, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 31, bv_val = 0xcd02f0 "cn=ldaproot,dc=csupomona ,dc=edu"}, sai_ndn = { sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f5060004198, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7f5060102c10 "20161225113103.634923Z#000000#000#000000" }, o_private = 0x0, o_extra = {slh_first = 0x7f50727fb430}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 3, oh_conn = 0x7f50727fc340, oh_msgid = 0, oh_protocol = 0, oh_tid = 139983495091968, oh_threadctx = 0x7f50727fcb90, oh_tmpmemct x = 0x7 oh_tmpmfuncs = 0x7787a0 <slap_sl_mfuncs>, oh_counters = 0x7ae000 <sl ap_counters>, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>, oh_exten sions = 0x0}, ob_controls = { 0x0 <repeats 17 times>, 0x7f50727fbd00, 0x0 <repeats 14 times>}} op = 0x7f50727fc600 rc = 0 dostop = 0 s = 16 i = <optimized out> defer = 1 fail = 0 freeinfo = 0 be = 0xcd0ac0 #8 0x0000000000433037 in connection_read_thread (ctx=0x7f50727fcb90, argv=0x10) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/connection.c :1296 rc = <optimized out> cri = {op = 0x0, func = 0x4954b0 <do_syncrepl>, arg = 0xcd8a00, ctx = <o ptimized out>, nullop = <optimized out>} s = <optimized out> #9 0x00007f5272c83a32 in ldap_int_thread_pool_wrapper (xpool=0xc63a40) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/libraries/libldap_r/tpool. c:696 pool = 0xc63a40 task = 0x7f50a8000a20 work_list = <optimized out> ctx = {ltu_id = 139983495091968, ltu_key = {{ltk_key = 0x430810 <conn_co unter_init>, ltk_data = 0x7f5060000d20, ltk_free = 0x4308f0 <conn_counter_destr oy>}, { ltk_key = 0x486ac0 <slap_sl_mem_init>, ltk_data = 0x7f5060000e30, ltk_free = 0x486990 <slap_sl_mem_destroy>}, {ltk_key = 0x445cd0 <s lap_op_free>, ltk_data = 0x7f50a0113e10, ltk_free = 0x445c30 <slap_op_q_destroy> }, {ltk_key = 0xf85de0, ltk_data = 0x7f5060102fd0, ltk_free = 0x7f526dfda950 <mdb_reader_f ree>}, { ltk_key = 0x7f526dfd07d0 <search_stack>, ltk_data = 0x7f5070ffc010 , ltk_free = 0x7f526dfd08e0 <search_stack_free>}, {ltk_key = 0x7f526 dfd0730 <scope_chunk_get>, ltk_data = 0x7f5060104e60, ltk_free = 0x7f526dfd08b0 <scope_chunk_ free>}, {ltk_key = 0xd7f560, ltk_data = 0x7f50604ab8f0, ltk_free = 0x7f526dfda950 <mdb_reader_f ree>}, {ltk_key = 0x0, ltk_data = 0x7f506c40fff0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_da ta = 0x0, ltk_free = 0x0} <repeats 24 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"

1 0

Re: (ITS#8575) Argon2 Password hashing contrib module
by quanah＠symas.com 04 Mar '17

04 Mar '17

--On Thursday, January 26, 2017 1:36 PM +0000 simon(a)slevermann.de wrote: > This patch adds a password hashing module for the argon2 function to the > contrib/slapd-modules/passwd/ modules. Argon2 is a relatively new hash > function which has won the Password Hashing Competition > (https://password-hashing.net) Discussed with Simon in IRC, he is going to look at making the modifications necessary so that this module can also use libsodium. --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#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 03 Mar '17

03 Mar '17

--On Friday, March 03, 2017 9:57 PM +0000 quanah(a)symas.com wrote: > Your context for points 1-3 are invalid as the entire issue was around > N-way MMR (and their individual serverID contextCSNs) so non-master > replicas are beside the point. In addition, a correct setup via the most > recent tools would include replicas pulling from all masters, vs a single > master. So there is no replica only pulling from an "active" or > "passive" master in a correct setup. Replicas pull from *all* masters > when deployed correctly. See also > <https://bugzilla.zimbra.com/show_bug.cgi?id=95200> For background on ITS#8281, the context was: 2 (or more) MMR nodes fully populated with X number of entries. Add a new MMR node (with no database populated) While the MMR node is in REFRESH mode, stop/start slapd on that node. The interuption in the REFRESH phase results in the DB not fully replicating (Stopped at the point in which slapd was stopped). This is clearly described in the initial report, where only 625/15000 users got replicated due to stopping slapd. The discussion about what to do when there's no contextCSN generated yet on a new system, where it is single master/consumer was an orthogonal but related discussion, in relation to the value of generating a contextCSN at startup or not. --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#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 03 Mar '17

03 Mar '17

--On Friday, March 03, 2017 9:36 PM +0000 mberg(a)synacor.com wrote: > I'm not precisely sure how this relates to 8281, since that seemed to > be fixed by not generating an initial contextCSN for newly initialized > databases and telling consumers to smeg off if they tried to connect > before a contextCSN was written (presumably by a successful REFRESH in > a newly initialized MMR provider, or an initial write in a single- > master provider). See <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=cd8f…>, where the code was clearly modified to push the contextCSN's through where before they were not. The entire issue around ITS#8281 was REFRESH mode in MMR failing if the server was stopped and restarted midstream while doing the refresh, with the wrong CSN value being stored. The changes in ITS#8281 ensure it maintains the correct CSN value internally. Your context for points 1-3 are invalid as the entire issue was around N-way MMR (and their individual serverID contextCSNs) so non-master replicas are beside the point. In addition, a correct setup via the most recent tools would include replicas pulling from all masters, vs a single master. So there is no replica only pulling from an "active" or "passive" master in a correct setup. Replicas pull from *all* masters when deployed correctly. See also <https://bugzilla.zimbra.com/show_bug.cgi?id=95200> --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#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 03 Mar '17

03 Mar '17

On Thu, 2017-03-02 at 16:49 -0800, Quanah Gibson-Mount wrote: > --On Thursday, March 02, 2017 10:36 PM +0000 mberg(a)synacor.com wrote: > > > I'm not sure if there is any guard against writing an older > > contextCSN > > than is currently stored, but this could theoretically rewind the > > stored contextCSN on A if there is any latency in replication from > > B. > > Older contextCSNs will be ignored. And it is accurate to then have > a contextCSN for each server in the system. That was part of the > initial problem in 8281. I still see no evidence of incorrect > behavior. ;) I'm well aware that there will be a contextCSN for each SID in the system. The questionable part was the apparent overwriting of the contextCSN on another server. I seem to be unable to reproduce that today, so I'm not sure if I fat-fingered something. However there would seem to be a couple possibilities here: 1) The contextCSN written as an accesslog entry is read by the other server and applied, which would be wrong since it should represent the most recent entryCSN seen for that SID, or 2) The contextCSN written as an accesslog entry is read by the other server and ignored, which would waste IOPS and increase latency, or 3) The contextCSN written as an accesslog entry has some non-obvious function, and replicas reading from the active master would be at a disadvantage since these entries are only being written on the passive master. I'm not precisely sure how this relates to 8281, since that seemed to be fixed by not generating an initial contextCSN for newly initialized databases and telling consumers to smeg off if they tried to connect before a contextCSN was written (presumably by a successful REFRESH in a newly initialized MMR provider, or an initial write in a single- master provider). This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

(ITS#8608) Inversion in filter pcacheTemplate cannot be parsed
by danmer＠danmer.net 03 Mar '17

03 Mar '17

Full_Name: Tabolin Yuriy Version: 2.4.43 OS: FreeBSD 10.1-RELEASE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (149.126.18.58) I use openldap 2.4.43 with pcache overlay. Inversion assertions in pcacheTemplate filter cannot be parsed and slapd cannot start. For example this works fine: overlay pcache pcache mdb 100000 1 1000 60 pcacheAttrset 0 * pcacheTemplate (objectClass=) 0 3600 3600 But this not: overlay pcache pcache mdb 100000 1 1000 60 pcacheAttrset 0 * pcacheTemplate (!(objectClass=)) 0 3600 3600 There is written in man slapo-pcache "A template is defined by a filter string and an index identifying a set of attributes. The template string for a query can be obtained by removing assertion values from the RFC 4515 representation of its search filter." RFC4515 have defined exclamation mark ("!") as inversion in filter.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 03 Mar '17

03 Mar '17

--On Thursday, March 02, 2017 10:36 PM +0000 mberg(a)synacor.com wrote: > I'm not sure if there is any guard against writing an older contextCSN > than is currently stored, but this could theoretically rewind the > stored contextCSN on A if there is any latency in replication from B. Older contextCSNs will be ignored. And it is accurate to then have a contextCSN for each server in the system. That was part of the initial problem in 8281. I still see no evidence of incorrect behavior. ;) --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#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 02 Mar '17

02 Mar '17

Storing the update to the contextCSN to the root object makes sense, but propagating that update through the accesslog? Even if it were intended behavior, shouldn't the server receiving the update directly generate a similar access log entry, rather than just the server applying it from the accesslog. But practically speaking, the contextCSN on a given server should presumably reflect the most recent entryCSN that particular server has applied, and this would seem to break that. To illustrate I added a third contextCSN to my lab servers, with a stale CSN on ldap01-a: [zimbra@ldap01-a ~ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN dn: contextCSN: 20170302203943.550330Z#000000#001#000000 contextCSN: 20170302175436.282737Z#000000#002#000000 contextCSN: 20160302175436.282737Z#000000#003#000000 [zimbra@ldap01-b ~]$ ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN dn: contextCSN: 20170302203943.550330Z#000000#001#000000 contextCSN: 20170302175436.282737Z#000000#002#000000 contextCSN: 20170302175436.282737Z#000000#003#000000 Wrote a new entry on ldap01-a (which is SID 001). The change propagated to ldap01-b, wrote an auditModify to the accesslog with its new contextCSNs: dn: reqStart=20170302214742.843377Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170302214742.843377Z reqEnd: 20170302214742.844297Z reqType: modify reqSession: 100 reqAuthzID: cn=config reqDN: reqResult: 0 reqMod: contextCSN:= 20170302214737.049475Z#000000#001#000000 reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000 reqMod: contextCSN:= 20170302175436.282737Z#000000#003#000000 reqEntryUUID: e1475404-93d7-1036-989f-315f78f5905f entryUUID: 9bceae9e-93dd-1036-8a51-85a9c542cb5f creatorsName: cn=config createTimestamp: 20170302214737Z entryCSN: 20170302214737.049475Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20170302214737Z Which was subsequently read by ldap01-a: Mar 2 16:47:42 ldap01-a slapd[9577]: syncprov_search_response: cookie=rid=100,sid=001,csn=20170302214737.049475Z#000000#001#000000 And now it has an updated contextCSN for 003 despite receiving no update for that SID: [zimbra@ldap01-a ~]$ ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN dn: contextCSN: 20170302214737.049475Z#000000#001#000000 contextCSN: 20170302175436.282737Z#000000#002#000000 contextCSN: 20170302175436.282737Z#000000#003#000000 I'm not sure if there is any guard against writing an older contextCSN than is currently stored, but this could theoretically rewind the stored contextCSN on A if there is any latency in replication from B. This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 02 Mar '17

02 Mar '17

--On Thursday, March 02, 2017 6:46 PM +0000 mberg(a)synacor.com wrote: > In order to rule out the possibility that this was introduced by any > patched Zimbra applied I built out a new package from stock OpenLDAP > sources and was able to reproduce with both 2.4.44 and 2.4.43, but not > with 2.4.42 and earlier. Hi Matt, I don't see any indication of a bug here. Zimbra uses "" (empty DN) as its root, which shares other responsibilities with the overal DIT. So it's simply logging an update of the contextCSN to its root entry. This change in behavior was made to resolve the issue I reported in ITS#8281. Closing this report. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 02 Mar '17

02 Mar '17

Full_Name: Matthew Berg Version: 2.4.43+ OS: CentOS 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.97.88.240) While debugging replication issues in a Zimbra installation, I discovered a significant number of accesslog entries with an empty reqDN and specifying values for contextCSN; e.g. dn: reqStart=20170302180943.186147Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170302180943.186147Z reqEnd: 20170302180943.190880Z reqType: modify reqSession: 100 reqAuthzID: cn=config reqDN: reqResult: 0 reqMod: contextCSN:= 20170227211132.933390Z#000000#000#000000 reqMod: contextCSN:= 20170302180943.182601Z#000000#001#000000 reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000 entryUUID: 27b9f34c-93bf-1036-9636-3fa0e78444ec creatorsName: cn=config createTimestamp: 20170302180943Z entryCSN: 20170302180943.182601Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20170302180943Z I was able to reproduce this behavior in a test lab with two freshly installed servers and no existing data. Given two servers, A and B, a write to A will result in the expected audit object being written to the access log on A, but when B applies the change it logs an additional auditModify (likewise B will cause the same additional entry on A). This particular environment was running a patched build of 2.4.44. I audited our other production environments and did not see the same behavior with prior builds (primarily 2.4.39). In order to rule out the possibility that this was introduced by any patched Zimbra applied I built out a new package from stock OpenLDAP sources and was able to reproduce with both 2.4.44 and 2.4.43, but not with 2.4.42 and earlier.

1 0

(ITS#8606) Document the keepalive parameter in the admin guide
by quanah＠openldap.org 02 Mar '17

02 Mar '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The keepalive parameter to syncrepl was added after the current replication documents were written, and needs to be added to the admin guide.

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by quanah＠symas.com 01 Mar '17

01 Mar '17

--On Tuesday, February 14, 2017 3:16 AM +0000 ryan(a)nardis.ca wrote: > I found that useful in a setup very similar to what Andreas and Michael > describe: slapd with a server certificate issued by an external/public > CA, but trusting only a specific internal CA to authenticate clients. I found this to be a very common scenario while working for Zimbra. Many of the clients had a commercial sever cert but used their own CA for internal client cert auth. It would be extremely helpful for OpenLDAP to better support these types of configurations. --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#8605) spelling
by quanah＠symas.com 28 Feb '17

28 Feb '17

--On Sunday, February 26, 2017 8:20 AM +0000 jsoref(a)gmail.com wrote: > Full_Name: Josh Soref > Version: master > OS: > URL: > https://github.com/openldap/openldap/compare/master...jsoref:spelling?exp > and=1 Submission from: (NULL) (135.23.187.91) > > > This is a proposal of 144 changes. They should each be individually > applicable (although some may require earlier changes if they happen to > touch similar lines). > > Please don't expect me to submit 144 individual change requests, that > isn't reasonable. I am generally willing to provide 3-10 submissions, > preferably on the lower side. All you have to do is specify what you want > in them. Hi Josh, These look good, and I think it can be done as a single git-format-patch submission uploaded to the FTP server. 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#8605) spelling
by jsoref＠gmail.com 26 Feb '17

26 Feb '17

Full_Name: Josh Soref Version: master OS: URL: https://github.com/openldap/openldap/compare/master...jsoref:spelling?expan… Submission from: (NULL) (135.23.187.91) This is a proposal of 144 changes. They should each be individually applicable (although some may require earlier changes if they happen to touch similar lines). Please don't expect me to submit 144 individual change requests, that isn't reasonable. I am generally willing to provide 3-10 submissions, preferably on the lower side. All you have to do is specify what you want in them.

1 0

(ITS#8604) back-config breaks on Solaris 8/9
by quanah＠openldap.org 24 Feb '17

24 Feb '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) Filing for historical purposes: The stdio library on this version of Solaris doesn't understand %z. Change the definition (slapd/config.c around line 58). In the not _WIN32 case, add #ifdef __sun #if _SIZEOF_SIZE_T_ == 4 #define Z "ll" #define LUTIL_ATOULX lutil_atoullx #else #define Z "l" #define LUTIL_ATOULX lutil_atoulx #else ... (existing defs: LUTIL_ATOULX -> lutil_atoulx, Z -> "z" #endif #endif Otherwise one will see: 54505a71 config_build_attrs: error 21 on olcDbCacheSize value #0 54505a71 config_build_entry: build "zu" failed: "" 54505a71 backend_startup_one (type=config, suffix="cn=config"): bi_db_open failed! (-1)

1 0

Re: (ITS#8590) LMDB: Suppress SIGPIPE in mdb_env_copythr on OS X
by lmb＠cloudflare.com 23 Feb '17

23 Feb '17

I should probably mention that this bug will make compacting copies lock up on OS X, since the copy thread blocks in sigwait forever if the process set SIG_IGN on SIGPIPE. Regards, Lorenz

1 0

Re: (ITS#8485) [PATCH] Adding support for encrypted server private keys
by ahnolds＠gmail.com 23 Feb '17

23 Feb '17

--001a11447608411b0a054928d3c2 Content-Type: text/plain; charset=UTF-8 I completely agree that this doesn't add any security when running slapd. However, when I originally wrote this patch, I was more targeting API usage, and in particular, client-side API usage. My goal was to allow a user to present an encrypted key (stored on disk) and a password (only held in memory), and use these to query a secure LDAP server. The issue of how the password got into memory is certainly beyond the scope of OpenLDAP in this case, but it certainly could be done securely in a way that wouldn't leave it exposed to a third-party with file-system access. For example (in the use case that motivated me originally), an sysadmin could input the password through an online form, submit said form to a Python webserver over HTTPS, the Python code could pass the password to OpenLDAP through a Python interface like python-ldap ( https://www.python-ldap.org/), and then use the LDAPS or STARTTLS connection to talk securely to some LDAP server elsewhere. All without an unencrypted keyfile or a password ever existing on disk, hence the added security. If you feel that supporting encrypted keyfiles in slapd is a bad design choice, I'm willing to rework the patch to drop that part and only keep the API-level support. Personally, I would argue that it doesn't hurt to support the feature, although perhaps my documentation changes could do a better job emphasizing the inherent security limitations. Let me know what you think (or if this discussion should take place on a list, let me know which/where). On Wed, Feb 22, 2017 at 1:11 PM, Howard Chu <hyc(a)symas.com> wrote: > ahnolds(a)gmail.com wrote: > >> Full_Name: Alec Cooper >> Version: HEAD of master branch >> OS: Ubuntu Linux 16.04 >> URL: ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch >> Submission from: (NULL) (73.134.243.211) >> >> >> Adding support for encrypted server private keys. >> > > Thank you for your submission. I must compliment you on providing such a > comprehensive and well-written contribution. Unfortunately the feature > itself is clearly not useful. Perhaps you should have raised this topic on > the openldap-devel list for discussion before spending your time writing it. > > All your feature does is embed the encryption key in the filesystem, so an > encrypted private key is still no more secure than an unencrypted one. It > still just depends on setting proper file access permissions, and the > current documentation already makes that point. > > Indeed, all it does is give the false illusion of enhancing security, and > followups like balmerpeak92(a)gmail.com's shows that people will easily > fall for such illusions. > > I regret having to reject such a well written contribution, but we cannot > in good conscience accept a security feature that doesn't actually improve > security. > >> >> The meat of this patch is changes to tls2.c, tls_g.c, tls_m.c, and >> tls_o.c to >> send a password to the underlying TLS library. >> >> Changes to ldap.h, init.c and ldap-int.h expose the new >> LDAP_OPT_X_TLS_KEYPASSWORD in the main API. >> >> Changes in the contrib/ldapc++ directory expose the corresponding >> TlsOptions::KEYPASSWORD option in the C++ API. >> >> Changes in the servers directory expose equivalent options for servers as >> configuration file entries or environment variables. >> >> Changes in the doc directory add documentation about the new options and >> remove >> statements that indicated that encrypted keyfiles are not supported. >> >> New files in the test directory are for testing TLS connections, both in >> general >> and with encrypted keyfiles. Tests pass for OpenSSL and GnuTLS using PEM >> formatted certs and keys, and for MozNSS using cert/key databases. The >> new unit >> test (test065-tls) has been written to detect when using NSS, and use the >> cert/key databases in this case. I have been unable to get a working >> version of >> libnsspem, so I cannot test MozNSS with (or without) encrypted keyfiles - >> testing for this case would be welcome! >> >> Notice of origin: The attached patch file is derived from OpenLDAP >> Software. All >> of the modifications to OpenLDAP Software represented in the following >> patch >> were developed by Alec Cooper ahnolds(a)gmail.com. I have not assigned >> rights >> and/or interest in this work to any party. >> Rights statement: I, Alec Cooper, 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. >> >> The patch has been uploaded to the OpenLDAP FTP server and can be found at >> ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a11447608411b0a054928d3c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I completely agree that this doesn't add any security = when running slapd. However, when I originally wrote this patch, I was more= targeting API usage, and in particular, client-side API usage. My goal was= to allow a user to present an encrypted key (stored on disk) and a passwor= d (only held in memory), and use these to query a secure LDAP server. The i= ssue of how the password got into memory is certainly beyond the scope of O= penLDAP in this case, but it certainly could be done securely in a way that= wouldn't leave it exposed to a third-party with file-system access.<di= v><br></div><div>For example (in the use case that motivated me originally)= , an sysadmin could input the password through an online form, submit said = form to a Python webserver over HTTPS, the Python code could pass the passw= ord to OpenLDAP through a Python interface like python-ldap (<a href=3D"htt= ps://www.python-ldap.org/">https://www.python-ldap.org/</a>), and then use = the LDAPS or STARTTLS connection to talk securely to some LDAP server elsew= here. All without an unencrypted keyfile or a password ever existing on dis= k, hence the added security.<div><br></div><div>If you feel that supporting= encrypted keyfiles in slapd is a bad design choice, I'm willing to rew= ork the patch to drop that part and only keep the API-level support. Person= ally, I would argue that it doesn't hurt to support the feature, althou= gh perhaps my documentation changes could do a better job emphasizing the i= nherent security limitations. Let me know what you think (or if this discus= sion should take place on a list, let me know which/where).=C2=A0</div></di= v><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q= uote">On Wed, Feb 22, 2017 at 1:11 PM, Howard Chu <span dir=3D"ltr"><<a = href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></span= > wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:ahnolds@gmail.= com" target=3D"_blank">ahnolds(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Alec Cooper<br> Version: HEAD of master branch<br> OS: Ubuntu Linux 16.04<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch" r= el=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incomin<wbr>g/Al= ec-Cooper-160827.patch</a><br> Submission from: (NULL) (73.134.243.211)<br> <br> <br> Adding support for encrypted server private keys.<br> </blockquote> <br> Thank you for your submission. I must compliment you on providing such a co= mprehensive and well-written contribution. Unfortunately the feature itself= is clearly not useful. Perhaps you should have raised this topic on the op= enldap-devel list for discussion before spending your time writing it.<br> <br> All your feature does is embed the encryption key in the filesystem, so an = encrypted private key is still no more secure than an unencrypted one. It s= till just depends on setting proper file access permissions, and the curren= t documentation already makes that point.<br> <br> Indeed, all it does is give the false illusion of enhancing security, and f= ollowups like <a href=3D"mailto:balmerpeak92@gmail.com" target=3D"_blank">b= almerpeak92(a)gmail.com</a>'s shows that people will easily fall for such= illusions.<br> <br> I regret having to reject such a well written contribution, but we cannot i= n good conscience accept a security feature that doesn't actually impro= ve security.<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> The meat of this patch is changes to tls2.c, tls_g.c, tls_m.c, and tls_o.c = to<br> send a password to the underlying TLS library.<br> <br> Changes to ldap.h, init.c and ldap-int.h expose the new<br> LDAP_OPT_X_TLS_KEYPASSWORD in the main API.<br> <br> Changes in the contrib/ldapc++ directory expose the corresponding<br> TlsOptions::KEYPASSWORD option in the C++ API.<br> <br> Changes in the servers directory expose equivalent options for servers as<b= r> configuration file entries or environment variables.<br> <br> Changes in the doc directory add documentation about the new options and re= move<br> statements that indicated that encrypted keyfiles are not supported.<br> <br> New files in the test directory are for testing TLS connections, both in ge= neral<br> and with encrypted keyfiles. Tests pass for OpenSSL and GnuTLS using PEM<br= > formatted certs and keys, and for MozNSS using cert/key databases. The new = unit<br> test (test065-tls) has been written to detect when using NSS, and use the<b= r> cert/key databases in this case. I have been unable to get a working versio= n of<br> libnsspem, so I cannot test MozNSS with (or without) encrypted keyfiles -<b= r> testing for this case would be welcome!<br> <br> Notice of origin: The attached patch file is derived from OpenLDAP Software= . All<br> of the modifications to OpenLDAP Software represented in the following patc= h<br> were developed by Alec Cooper <a href=3D"mailto:ahnolds@gmail.com" target= =3D"_blank">ahnolds(a)gmail.com</a>. I have not assigned rights<br> and/or interest in this work to any party.<br> Rights statement: I, Alec Cooper, hereby place the following modifications = to<br> OpenLDAP Software (and only these modifications) into the public domain. He= nce,<br> these modifications may be freely used and/or redistributed for any purpose= with<br> or without attribution and/or other notice.<br> <br> The patch has been uploaded to the OpenLDAP FTP server and can be found at<= br> <a href=3D"ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch" rel=3D= "noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incomin<wbr>g/Alec-Co= oper-160827.patch</a><br> <br> <br><span class=3D"HOEnZb"><font color=3D"#888888"> </font></span></blockquote><span class=3D"HOEnZb"><font color=3D"#888888"> <br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= c<wbr>t/</a><br> </font></span></blockquote></div><br></div> --001a11447608411b0a054928d3c2--

1 0

Re: (ITS#8574) bconfig support for DNs that need escaping
by okuznik＠symas.com 22 Feb '17

22 Feb '17

On Wed, Feb 22, 2017 at 06:34:18PM +0000, Ond=C5=99ej Kuzn=C3=ADk wrote: > On Wed, Feb 22, 2017 at 05:42:39PM +0000, Howard Chu wrote: >> okuznik(a)symas.com wrote: >>> When an rdn under cn=3Dconfig needs escaping, incorrect value gets pa= ssed to the >>> attribute and, if the attribute is single-value, the entry is rejecte= d by >>> entry_naming_check(). >>>=20 >>> Patch against master is attached. >>=20 >> Why are you running the normalizer in a for-loop: >>=20 >> + for ( cnt =3D 0; rDN[cnt]; cnt++ ) { >>=20 >> but always setting value #0? >>=20 >> + free( a->a_vals[0].bv_val ); >> + ber_dupbv( &a->a_vals[0], &ava->la_value ); >>=20 >> If the RDN is actually a compound with multiple AVAs you need to conca= tenate >> them into a single value. Otherwise, if you don't intend to support co= mpound >> RDNs, there's no point in using a for-loop. Just return an error if th= ere's >> more than one AVA. >=20 > While X-ORDERED 'SIBLINGS' are required to the single-valued in the > draft and back-config doesn't actually use multi-valued rDNs, it might > break if the latter ever changes. An updated fix is here: >=20 > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170222-Deal-with-rDN-co= rrectly.patch >=20 > This will still pick the value if the rDN is multi-valued, this time > regardless of the attribute's position in the rDN. As pointed out by Howard, the patch was not against master (although my git doesn't complain anyway). The following patch is and also tests that the attribute we were asked to update is actually present in the rDN provided: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170222b-Deal-with-rDN-cor= rectly.patch

1 0

Re: (ITS#8574) bconfig support for DNs that need escaping
by okuznik＠symas.com 22 Feb '17

22 Feb '17

On Wed, Feb 22, 2017 at 05:42:39PM +0000, Howard Chu wrote: > okuznik(a)symas.com wrote: >> When an rdn under cn=config needs escaping, incorrect value gets passed to the >> attribute and, if the attribute is single-value, the entry is rejected by >> entry_naming_check(). >> >> Patch against master is attached. > > Why are you running the normalizer in a for-loop: > > + for ( cnt = 0; rDN[cnt]; cnt++ ) { > > but always setting value #0? > > + free( a->a_vals[0].bv_val ); > + ber_dupbv( &a->a_vals[0], &ava->la_value ); > > If the RDN is actually a compound with multiple AVAs you need to concatenate > them into a single value. Otherwise, if you don't intend to support compound > RDNs, there's no point in using a for-loop. Just return an error if there's > more than one AVA. While X-ORDERED 'SIBLINGS' are required to the single-valued in the draft and back-config doesn't actually use multi-valued rDNs, it might break if the latter ever changes. An updated fix is here: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170222-Deal-with-rDN-correc… This will still pick the value if the rDN is multi-valued, this time regardless of the attribute's position in the rDN. Ondrej

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs