openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

Re: (ITS#8629) slapauth segfault with GSSAPI + olcAuthzRegexp using internal LDAP search + ppolicy overlay
by clement.oudot＠savoirfairelinux.com 06 Apr '17

06 Apr '17

Hello, I would like to know if some of you have an idea on how to fix this bug? I am able to test a patch if you can provide one. Regards, Cl=E9ment.

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by henson＠acm.org 05 Apr '17

05 Apr '17

On Mon, Apr 03, 2017 at 11:15:17AM -0700, Quanah Gibson-Mount wrote: > Looks like this has actually been reported before: > <http://www.openldap.org/its/index.cgi/?findid=7400> Yikes, from 2012, and never resolved 8-/. I'm curious though why Howard says the work has to be distributed to all the replicas locally as it wouldn't scale otherwise? For adding or removing a user from a group, replicating the memberOf attribute on the user in addition to the member attribute on the group only doubles the replication load which doesn't seem excessive. I suppose if you delete a group with a large membership that would result in updating a large number of users, but that's no different than if a delete a single user from a large number of groups, which doesn't seem to cause any issues. Unless I'm misunderstanding something? In any case, I suppose this ITS can be closed now too, with the same resolution that the memberof overlay is no longer supported in a replicated configuration and to switch to the dynlist implementation...

1 0

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

05 Apr '17

On Mon, Apr 03, 2017 at 02:44:48PM +0100, Howard Chu wrote: > You should probably switch to a non-optimized build. The backtrace you > posted initially had most parameters optimized out, which also makes > things harder to trace. Ok, I installed binaries built with -O0 on the master server that's been failing; I'll post a new backtrace the next time it crashes, thanks.

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 05 Apr '17

05 Apr '17

--On Thursday, April 06, 2017 2:02 AM +0100 Howard Chu <hyc(a)symas.com> wrote: >> +#if OPENSSL_VERSION_NUMBER < 0x10100000 > > Are you sure about exactly when these functions were removed? The title > of this ITS is for 1.1.0c, and the earlier patches were for 1.1.0a. For > version 1.1.0c we should be comparing to 0x1010003f, not 0x10100000. Yes, I checked against OpenSSL 1.1.0 (released before 1.1.0a). The OpenSSL shipped headers are clear on this as well, for example: #if OPENSSL_API_COMPAT < 0x10100000L # define SSL_library_init() OPENSSL_init_ssl(0, NULL) #endif #if OPENSSL_API_COMPAT < 0x10100000L # define SSL_load_error_strings() \ OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS \ | OPENSSL_INIT_LOAD_CRYPTO_STRINGS, NULL) #endif etc -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs