openldap-bugs March 2017

openldap-bugs@openldap.org

31 participants
112 discussions

(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 08 Mar '17

08 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 08 Mar '17

08 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2017