openldap-bugs August 2016

openldap-bugs@openldap.org

21 participants
50 discussions

(ITS#8479) overlay unique + mdb: loop and OOM kill, 2 URS as olcUniqueURI value
by william.b.clay＠acm.org 15 Aug '16

15 Aug '16

Full_Name: Bill Clay Version: 2.4.44 OS: Debian/GNU Linux 7.8 (Wheezy) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.15.115.130) The below modification to an otherwise correctly-functioning slapd instance provokes an infinite loop that eventually ends with allocation of all configured virtual memory, kernel invocation of its oom-killer (generally on an innocent bystander), and sometimes a kernel panic. This scenario is 100% repeatable on this installation. If I understand "man 5 slapo-unique" correctly, an instance of overlay unique may specify more than one olcUniqueURI attribute, each of which may specify more than one space-separated (?) URI. In this case, I am replacing two initially-configured olcUniqueURI attributes whose values comprise a single URI each (and which seem to work correctly) by one olcUniqueURI attribute with two URIs. bill@fuji:~$ sudo ldapmodify -YEXTERNAL -Hldapi:// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:olcOverlay={2}unique,olcDatabase={3}mdb,cn=config changetype: modify replace: olcUniqueURI olcUniqueURI: ldap:///ou=gruppi,dc=test?gidNumber?one ldap:///ou=gruppi,dc=test?owner?one modifying entry "olcOverlay={2}unique,olcDatabase={3}mdb,cn=config" ldap_result: Can't contact LDAP server (-1) bill@fuji:~$ This slapd is the following custom build on an otherwise fairly stock Debian Wheezy system. cd /usr/local/src/openldap-2.4.44 ./configure --sysconfdir=/etc --localstatedir=/ \ --disable-backends --enable-mdb --enable-monitor --enable-crypt \ --with-cyrus-sasl --enable-spasswd --enable-syslog --enable-local \ --disable-overlays --enable-memberof --enable-refint --enable-unique \ --disable-modules --with-cyrus-sasl --with-tls --with-threads --with-gnu-ld # if --enable-shell, avoid --with threads I have uploaded files bill-clay-160815-<type>.txt to ftp://ftp.openldap.org/incoming/ for the following <types>: log: console log of slapd running foreground with -d1 (serial console at 57600 bps, allowing prompt manual termination via kill -KILL) cnf1-cnf3: slapadd specification of (1) the rootDSE, (2) {2}mdb's tree dc=epici,dc=it, and (3) {3}mdb's tree dc=test (subject of the failed ldapmodify). As is probably obvious from these files, I am an LDAP newbie, so there may be a configuration error here that's painfully obvious to the experienced practictioner.

1 0

Re: (ITS#8478) Master/Slave Replication not catching up if syncrepl config is defined before the replication user exist
by hyc＠symas.com 12 Aug '16

12 Aug '16

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.42 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.247.10.144) > > > When configuring syncrepl using slapd.d on a slave, if the replicator user does > not exist beforehand, replication won't catch with entries that were updated > prior the creation of the replicator user on the slave. OTOH, if we create this > replicator user *before* setting the replication configuration on the slave, > every updated entries on the master are replicated, even those created before > the configuration modification. Please provide a sample config that demonstrates the issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8478)
by elecharny＠gmail.com 12 Aug '16

12 Aug '16

IMO, it's a different issue. Ther ei no timing issue, it's reproductible in any case. FTR, I tested it on 2.4.44 (even if the original issue was seen on 2.4.42) The key here is really to create the replicator user before or after configuring syncrepl on the slave : if the user is created first, then all the entries get replicated from the master, and if teh user is created after the syncrepl configuration, no entry older than the moment the replicator user is added are read from the master.

1 0

Re: (ITS#8478) Master/Slave Replication not catching up if syncrepl config is defined before the replication user exist
by quanah＠zimbra.com 12 Aug '16

12 Aug '16

--On Friday, August 12, 2016 4:42 PM +0000 elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.42 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.247.10.144) > > > When configuring syncrepl using slapd.d on a slave, if the replicator > user does not exist beforehand, replication won't catch with entries that > were updated prior the creation of the replicator user on the slave. > OTOH, if we create this replicator user *before* setting the replication > configuration on the slave, every updated entries on the master are > replicated, even those created before the configuration modification. Is this any different from ITS#8281, ITS#8365? It sounds quite similar. Have you tested on a current release, which is general best practices before filing an ITS? --Quanah -- Quanah Gibson-Mount

1 0

(ITS#8478) Master/Slave Replication not catching up if syncrepl config is defined before the replication user exist
by elecharny＠apache.org 12 Aug '16

12 Aug '16

Full_Name: Emmanuel L.charny Version: 2.4.42 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.247.10.144) When configuring syncrepl using slapd.d on a slave, if the replicator user does not exist beforehand, replication won't catch with entries that were updated prior the creation of the replicator user on the slave. OTOH, if we create this replicator user *before* setting the replication configuration on the slave, every updated entries on the master are replicated, even those created before the configuration modification.

1 0

Re: (ITS#8477) OpenLDAP.org has a broken TLS certificate
by demiobenour＠gmail.com 10 Aug '16

10 Aug '16

On Wed, 2016-08-10 at 21:13 +0100, Howard Chu wrote: > demiobenour(a)gmail.com wrote: > > > > Full_Name: Demi Obenour > > Version: N/A > > OS: N/A > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (2601:840:8100:6720:2ae3:47ff:fe02:d99e) > > > > > > OpenLDAP.org has an expired self-signed TLS certificate, > > This is intentional. > > > > > which makes it > > impossible to securely access the Git repositories over HTTPS. > > The repos are only intended to be used via git: and http: anyway. > > This needs to be > > > > fixed to avoid man-in-the-middle attacks, which would allow > > arbitrary code > > execution on the developer's machine. > > When I discussed this with Kurt, we decided to leave things as-is. > Replacing > an expired self-signed cert with a non-expired self-signed cert > wouldn't > change anything, you still need to set an explicit exception in your > client to > trust the cert. > Why are the repos only intended to be used via git: and http: ? Is there some reason? This makes them unusable for anyone who cares about security. In the past http:// and https:// used an old dumb protocol that was slow, but that has long since been fixed in Git. Also, why the self-signed certificate at all? Let's Encrypt is providing free certificates.

1 0

Re: (ITS#8477) OpenLDAP.org has a broken TLS certificate
by michael＠stroeder.com 10 Aug '16

10 Aug '16

hyc(a)symas.com wrote: > When I discussed this with Kurt, we decided to leave things as-is. Replacing > an expired self-signed cert with a non-expired self-signed cert wouldn't > change anything, you still need to set an explicit exception in your client to > trust the cert. Hmm, but browsers will likely not allow adding an exception anymore in the near future. And e.g. using Let's Encrypt isn't that hard (even without installing the bloated standard client on the system). Ciao, Michael.

1 0

Re: (ITS#8477) OpenLDAP.org has a broken TLS certificate
by hyc＠symas.com 10 Aug '16

10 Aug '16

demiobenour(a)gmail.com wrote: > Full_Name: Demi Obenour > Version: N/A > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2601:840:8100:6720:2ae3:47ff:fe02:d99e) > > > OpenLDAP.org has an expired self-signed TLS certificate, This is intentional. > which makes it > impossible to securely access the Git repositories over HTTPS. The repos are only intended to be used via git: and http: anyway. This needs to be > fixed to avoid man-in-the-middle attacks, which would allow arbitrary code > execution on the developer's machine. When I discussed this with Kurt, we decided to leave things as-is. Replacing an expired self-signed cert with a non-expired self-signed cert wouldn't change anything, you still need to set an explicit exception in your client to trust the cert. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8477) OpenLDAP.org has a broken TLS certificate
by demiobenour＠gmail.com 10 Aug '16

10 Aug '16

Full_Name: Demi Obenour Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:840:8100:6720:2ae3:47ff:fe02:d99e) OpenLDAP.org has an expired self-signed TLS certificate, which makes it impossible to securely access the Git repositories over HTTPS. This needs to be fixed to avoid man-in-the-middle attacks, which would allow arbitrary code execution on the developer's machine.

1 0

Re: (ITS#8475) Feature request: MDB low durability transactions
by bentrask＠comcast.net 10 Aug '16

10 Aug '16

Okay, thanks for taking the time to discuss, and of course for all your work on MDB! Ben On 08/10/2016 08:50 AM, Hallvard Breien Furuseth wrote: > Nope, you're as confused as I was originally:-) LDMB doesn't know or > care when a page was written. A page can be reused when the snapshot > which _freed_ it is known to be durable and there are no older readers. > (We could improve that by tracking page history better. Maybe later.) > > "Known to be durable" = sync datapages, write metapage, sync metapage, > note that the metapage was synced. (We implicitly note that when > writing next txn's metapage, since we must have synced first.) From > a data safety point of view, txns which do all that are the real txns. > Anything else is fluff, like no-sync txns if we implement them. Their > metapages must go somewhere they *won't* be confused with durable ones. > > Think of such a fluffy commit as saving an intermediate stage of a > real txn. That's irrelevant to a later write-txn wanting to not touch > the last two durable snapshots. It's only relevant vs. oldest reader. > > So. 3rd metapage and variants - I've tried and Howard pointed out > the flaws, Howard tried and I said here we go again. We do not need > another round, but it's just as well to have it summarized here. > > (This discussion ignores MDB_NOSYNC and partly MDB_NOLOCK - if the > user enables either, it's his responsibility to compensate.) >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2016