openldap-bugs April 2017

openldap-bugs@openldap.org

25 participants
116 discussions

Re: (ITS#6448) BUS Error on Multi Master Mode
by quanah＠symas.com 07 Apr '17

07 Apr '17

Hello, Thanks for the report, and I apologize for the delay in responding. I would note that 2.4.21 (at this point) is ancient, and there have been numerous fixes to Multimaster replication since that time. I would note in the future, if you choose to file a report, your exact configurations would also need to be supplied for a report such as this one. There was nothing particularly actionable based on this report. This ITS will be closed. If you can reproduce this issue with a current build of OpenLDAP, please file a new issue. 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#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 07 Apr '17

07 Apr '17

Today at 7:59am, ondra(a)mistotebe.net wrote: > Would you be able to confirm the patch in my previous email does the > right thing for you? I am building it now, I'll test and report back. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#7032) LDAP Server not answering a request
by quanah＠symas.com 07 Apr '17

07 Apr '17

Hello, Due to lack of response, this ITS will be closed. If you continue to encounter the issue with a current build of OpenLDAP, please file a new ITS. 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#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 07 Apr '17

07 Apr '17

On Thu, Apr 06, 2017 at 02:48:45PM +0000, Frank.Swasey(a)uvm.edu wrote: > On Wed, 5 Apr 2017 at 8:18am, ondra(a)mistotebe.net wrote: > >> AFAIK, LDAP doesn't forbid it so I don't see that going away. > > Well, then that means that the current behavior is a bug in either the > syncrepl implementation or the accesslog recording. Since the MASTER > gets updated correctly and the REPLICAs (and other MMR members) all fall > down when attempting to process the accesslog entry. Yes, they might reject the log entry and fall back to regular syncrepl in the way they would in case of a conflict (which is mostly fine), or the interpretation might seem to fit and a chance is that it's different that the actual modification, causing the servers to silently get out of sync. >> It does need a fair bit of attention, the problem is it's something that >> would require a format change and there are already existing consumers >> that would be affected. >> >> I'm going to try with a patch to record something like this: >> regMod: sn:= George >> regMod: : >> regMod: sn:= George >> >> Together with the relevant syncrepl updates. >> >> While consumers would still be affected, this should be quite rare and >> the current handling of that case would have been incorrect anyway. The >> change would then only make the silent failure a noisy one. > > Noisy in that the replica/mmr falls over dead or just logs more stuff? In case of delta-syncrepl, it should reject it and fall back to regular syncrepl. I can't vouch for anything else that consumes accesslog data obviously. > To be honest, my goal is consistency. I want the replicas (and > MMR mates) to all wind up with the same values the master has. Would you be able to confirm the patch in my previous email does the right thing for you? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 06 Apr '17

06 Apr '17

On Thu, Apr 06, 2017 at 04:41:19PM +0100, Howard Chu wrote: > ondra(a)mistotebe.net wrote: >> Well, the clients are allowed to request a lot of strange things, some >> of which border on a DoS: e.g. right now slapd can't disallow a modify >> request like: (pumping up an attribute to extreme size) > > Nor should we disallow any such thing. "Be liberal in what you accept." Yes, not disallow in principle, it was meant as focusing on an option to define some resource/processing limits before we even thought about the other example that is relatively benign. BTW, the patch is now available here. The empty attribute should have replicas fall back to regular syncrepl, where the ones that understand it will interpret it correctly. ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170406-ITS-6545-accesslog-f… -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by hyc＠symas.com 06 Apr '17

06 Apr '17

ondra(a)mistotebe.net wrote: > On Thu, Apr 06, 2017 at 05:14:15PM +0200, Michael Str=C3=83=C2=B6der wr= ote: >> ondra(a)mistotebe.net wrote: >>> On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael Str=C3=84=E2=80=9A=C3= =85=E2=80=BAder wrote: >>>> =3D> There could be a slapd per-backend configuation directive to di= sallow it with a >>>> strong hint in the docs recommending to disallow it when using delta= -syncrepl. >>>> >>>> Suggestion: >>>> disallow mod_attr_repeated >>> >>> In my view, that's more pain than it's worth. >> >> Hmm, I think slapd should be able to disallow a crazy modify request l= ike this: >> >> dn: cn=3Dfoobar,dc=3Dexample,dc=3Dcom >> changetype: modify >> replace: description >> description: foobar1 >> - >> replace: description >> description: foobar2 >> - >> .. >> replace: description >> description: foobar1000 >> - > > Well, the clients are allowed to request a lot of strange things, some > of which border on a DoS: e.g. right now slapd can't disallow a modify > request like: Nor should we disallow any such thing. "Be liberal in what you accept." > > dn: cn=3Dfoobar,dc=3Dexample,dc=3Dcom > changetype: modify > replace: description > description: foobar1 > description: foobar2 > ... > description: foobar1000 > > So there. If we can agree on a way to handle that, we might see whether > it could be repurposed. > > I should have a patch for the accesslog issue soon. > --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 06 Apr '17

06 Apr '17

On Thu, Apr 06, 2017 at 05:14:15PM +0200, Michael Ströder wrote: > ondra(a)mistotebe.net wrote: >> On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael StrĂśder wrote: >>> => There could be a slapd per-backend configuation directive to disallow it with a >>> strong hint in the docs recommending to disallow it when using delta-syncrepl. >>> >>> Suggestion: >>> disallow mod_attr_repeated >> >> In my view, that's more pain than it's worth. > > Hmm, I think slapd should be able to disallow a crazy modify request like this: > > dn: cn=foobar,dc=example,dc=com > changetype: modify > replace: description > description: foobar1 > - > replace: description > description: foobar2 > - > .. > replace: description > description: foobar1000 > - Well, the clients are allowed to request a lot of strange things, some of which border on a DoS: e.g. right now slapd can't disallow a modify request like: dn: cn=foobar,dc=example,dc=com changetype: modify replace: description description: foobar1 description: foobar2 ... description: foobar1000 So there. If we can agree on a way to handle that, we might see whether it could be repurposed. I should have a patch for the accesslog issue soon. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by michael＠stroeder.com 06 Apr '17

06 Apr '17

ondra(a)mistotebe.net wrote: > On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael Ströder wrote: >> ondra(a)mistotebe.net wrote: >>> On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >>>> Thanks for the patch to provide a test script that just shows the same >>>> thing. >>>> >>>> I see two possible solutions: >>>> >>>> 1) replacing the same attribute twice in the same modify LDIF is illegal >>>> (as it was in older releases) >>> >>> AFAIK, LDAP doesn't forbid it so I don't see that going away. >> >> Yes, there's no text in RFC 4511 which forbids this: >> https://tools.ietf.org/html/rfc4511#section-4.6 >> >> However personally I consider LDAP clients sending modify requests like this to be >> broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) > > I'm not saying it's common or good practice ;) > >> => There could be a slapd per-backend configuation directive to disallow it with a >> strong hint in the docs recommending to disallow it when using delta-syncrepl. >> >> Suggestion: >> disallow mod_attr_repeated > > In my view, that's more pain than it's worth. Hmm, I think slapd should be able to disallow a crazy modify request like this: dn: cn=foobar,dc=example,dc=com changetype: modify replace: description description: foobar1 - replace: description description: foobar2 - .. replace: description description: foobar1000 - Ciao, Michael.

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 06 Apr '17

06 Apr '17

On Wed, 5 Apr 2017 at 8:18am, ondra(a)mistotebe.net wrote: > AFAIK, LDAP doesn't forbid it so I don't see that going away. Well, then that means that the current behavior is a bug in either the syncrepl implementation or the accesslog recording. Since the MASTER gets updated correctly and the REPLICAs (and other MMR members) all fall down when attempting to process the accesslog entry. > It does need a fair bit of attention, the problem is it's something that > would require a format change and there are already existing consumers > that would be affected. > > I'm going to try with a patch to record something like this: > regMod: sn:= George > regMod: : > regMod: sn:= George > > Together with the relevant syncrepl updates. > > While consumers would still be affected, this should be quite rare and > the current handling of that case would have been incorrect anyway. The > change would then only make the silent failure a noisy one. Noisy in that the replica/mmr falls over dead or just logs more stuff? To be honest, my goal is consistency. I want the replicas (and MMR mates) to all wind up with the same values the master has. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 06 Apr '17

06 Apr '17

On Wed, 5 Apr 2017 at 10:14am, michael(a)stroeder.com wrote: > However personally I consider LDAP clients sending modify requests like this to be > broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) My original report was from 2010 - I presume it was something that the perl code (using Net::LDAP module) that I had written at the time tripped onto [or it was some awful edgecase test that I had devised]. To the best of my knowledge, this was not something that I had a client doing to the LDAP servers from the wild. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

← Newer
1
...
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2017