openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

RE: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 30 Mar '17

30 Mar '17

--On Thursday, March 30, 2017 8:20 PM +0000 henson(a)acm.org wrote: >> From: Quanah Gibson-Mount >> Sent: Monday, March 27, 2017 8:09 AM >> >> There's too many outstanding issues to release 2.4.45, including this >> one. > > Well, are those new issues that don't exist in 2.4.44, or simply existing > bugs already in the wild that haven't been fixed? If the former, then > certainly you don't want to release fresh bugs 8-/, but if the latter, it > seems to me that pushing a release that improves the state of production > by fixing some known bugs, even if other existing known bugs still remain > to be quashed, is preferable than leaving a larger number of known bugs > at large on production systems :(. It seems the circular replication bug > is particularly bad, I'm surprised more people aren't having issues with > it. 2.4.43 introduced new bugs and those were continued in 2.4.44. I think it's important that the regressions are addressed before 2.4.45 is released. In addition, this very bug report indicates a regression between 2.4.44 and what's currently scheduled for 2.4.45, which is further reasoning not to release 2.4.45 at this time. --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#8626) TLS trace: SSL3 alert write:fatal:certificate unknown
by quanah＠symas.com 30 Mar '17

30 Mar '17

--On Thursday, March 30, 2017 10:14 AM +0000 anitha.seshadri(a)emc.com wrote: > Could you let us know what we could be missing here? Hello Anitha, It is clearly noted on the ITS submission page that the ITS system is for bug reports only. It is not meant for configuration and usage questions, such as what you have filed. The proper forum for configuration/usage questions is the openldap-technical list: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> I would additionally note that OpenLDAP 2.4.33 is closing in on 5 years old. I would strongly advise upgrading. In addition, you may wish to read over the documentation on certificates: <http://www.openldap.org/doc/admin24/tls.html> 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#8626 published: SECURITY: TLS trace: SSL3 alert write:fatal:certificate unknown
by openldap-its＠OpenLDAP.org 30 Mar '17

30 Mar '17

Private ITS#8626 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8626

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by michael＠stroeder.com 30 Mar '17

30 Mar '17

ondra(a)mistotebe.net wrote: > The other reading is "using relax might let you do more, but you still > need the right permissions", which is closer to how manageDSAIt works > and it seems that's what OpenLDAP (but not slapo-constraint) does. The > hassle is that you need to check permissions if you want to follow that > and that's hard to do correctly if you're an overlay. AFAIK using Relax Rules control makes slapd finish a write operation in case a constraintViolation would be returned without this control provided the bound identity has manage privilege (and of course does not hit insufficientAccess before because of missing write privilege). IMO slapo-unique should do the very same. If the behaviour is unclear I'd hack a test configuration. Ciao, Michael.

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by ondra＠mistotebe.net 30 Mar '17

30 Mar '17

On Thu, Mar 30, 2017 at 05:13:47PM +0200, Michael Ströder wrote: > ondra(a)mistotebe.net wrote: >> Given that relax control is still allowed for everyone (and no ACL >> support for controls exists yet), this patch will buy us little. > > Please correct if I'm wrong but AFAIK you need 'manage' privilege to circumvent > constraints (e.g. slapo-constraint and slapo-ppolicy). You don't need to be granted ACL_MANAGE to bypass slapo-constraint. Just your providing -e '!relax' will do. Just that some features and operations (add/rename) are protected by an additional ACL_MANAGE check if you run with the relax control so they will fail unless you have that privilege. I guess there is some room in the interpretation of what draft-zeilenga-ldap-relax-01 says: "[it is] expected that use of this extension will be restricted by administrative and/or access controls" One options is that if you specify the control, especially since you have to make it critical, you should qualify for administrative permissions on that operation or have it fail regardless of whether it would ordinarily succeed. If OpenLDAP backends adhered to that reading, constraint would do the right thing now and unique would as well with the patches I provided. The other reading is "using relax might let you do more, but you still need the right permissions", which is closer to how manageDSAIt works and it seems that's what OpenLDAP (but not slapo-constraint) does. The hassle is that you need to check permissions if you want to follow that and that's hard to do correctly if you're an overlay. -- 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#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 30 Mar '17

30 Mar '17

> From: Ond=F8ej Kuzn=EDk > Sent: Monday, March 27, 2017 8:10 AM >=20 > I've had a look whether I could reproduce the issue somehow and there = is > a potential crasher if the accesslog entry contained "reqmod: > eduPersonAffiliation:+". Can you confirm whether you have entries like > this in your logdb? There aren't currently any entries like that in the log, although the = last crash was a week or two ago. I will check again right after the next = crash. However, here is one of the log entries that appeared to correlate with = what was being processed in the backtrace of one of the crashes: dn: reqStart=3D20170214120013.000001Z,cn=3Daccesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170214120013.000001Z reqEnd: 20170214120013.000002Z reqType: modify reqSession: 37859 reqAuthzID: cn=3Didmgmt,ou=3Duser,ou=3Dservice,dc=3Dcsupomona,dc=3Dedu reqDN: uid=3Dvntruong,ou=3Duser,dc=3Dcsupomona,dc=3Dedu reqResult: 0 reqMod: eduPersonAffiliation:=3D reqMod: eduPersonPrimaryAffiliation:=3D reqMod: csupomonaEduPersonAffiliation:=3D reqMod: entryCSN:=3D 20170214120013.628665Z#000000#000#000000 reqMod: modifiersName:=3D = cn=3Didmgmt,ou=3Duser,ou=3Dservice,dc=3Dcsupomona,dc=3Dedu reqMod: modifyTimestamp:=3D 20170214120013Z reqEntryUUID: bd5ba51c-7a1b-4bdb-8bf3-fe90552f5909 entryCSN: 20170214120013.628665Z#000000#000#000000 entryUUID: 4737c48c-e46e-45a4-ba4b-2eb61540b27b creatorsName: cn=3Daccesslog createTimestamp: 20170214120013Z modifiersName: cn=3Daccesslog modifyTimestamp: 20170214120013Z And it does not appear to have that signature. Thanks.

1 0

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

30 Mar '17

> From: Quanah Gibson-Mount > Sent: Monday, March 27, 2017 8:09 AM > > There's too many outstanding issues to release 2.4.45, including this one. Well, are those new issues that don't exist in 2.4.44, or simply existing bugs already in the wild that haven't been fixed? If the former, then certainly you don't want to release fresh bugs 8-/, but if the latter, it seems to me that pushing a release that improves the state of production by fixing some known bugs, even if other existing known bugs still remain to be quashed, is preferable than leaving a larger number of known bugs at large on production systems :(. It seems the circular replication bug is particularly bad, I'm surprised more people aren't having issues with it. > I would consider at least the patch for ITS#8413 as mandatory as well. Hmm, I haven't run into that one yet myself, but thanks for the pointer.

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by michael＠stroeder.com 30 Mar '17

30 Mar '17

ondra(a)mistotebe.net wrote: > Given that relax control is still allowed for everyone (and no ACL > support for controls exists yet), this patch will buy us little. Please correct if I'm wrong but AFAIK you need 'manage' privilege to circumvent constraints (e.g. slapo-constraint and slapo-ppolicy). Ciao, Michael.

1 0

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

30 Mar '17

Full_Name: Clement Oudot Version: 2.4.44 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.248.50.71) Hello, with a simple olcAuthzRegexp configuration like: olcAuthzRegexp: {0}uid=(.*),cn=gssapi,cn=auth ldap:///dc=example,dc=com???(uid=$1) And ppolicy overlay configured, for example like: dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE We have a segfault when running this command: $ /usr/local/openldap/sbin/slapauth -F /home/clement/configuration/openldap/example /slapd.d/ -v coudot -M GSSAPI Here is the GDB backtrace: Program received signal SIGSEGV, Segmentation fault. 0x000000000055644f in ppolicy_restrict (op=0x7fffffffd0e0, rs=0x7fffffffd070) at ppolicy.c:1379 1379 ppolicy.c: Aucun fichier ou dossier de ce type. (gdb) bt #0 0x000000000055644f in ppolicy_restrict (op=0x7fffffffd0e0, rs=0x7fffffffd070) at ppolicy.c:1379 #1 0x00000000004a55ca in overlay_op_walk (op=op@entry=0x7fffffffd0e0, rs=0x7fffffffd070, which=op_search, oi=0xa59ef0, on=0xa571d0) at backover.c:661 #2 0x00000000004a574e in over_op_func (op=0x7fffffffd0e0, rs=<optimized out>, which=<optimized out>) at backover.c:730 #3 0x0000000000487375 in slap_sasl2dn (opx=0x7fffffffd710, saslname=0x0, sasldn=0x7fffffffd310, flags=-16, flags@entry=2) at saslauthz.c:2008 #4 0x000000000048e42b in slap_sasl_getdn (conn=conn@entry=0x7fffffffd450, op=op@entry=0x7fffffffd710, id=id@entry=0x7fffffffd440, user_realm=0x0, dn=dn@entry=0x7fffffffd410, flags=flags@entry=2) at sasl.c:1891 #5 0x00000000004aba73 in do_check (c=c@entry=0x7fffffffd450, op=op@entry=0x7fffffffd710, id=id@entry=0x7fffffffd440) at slapauth.c:44 #6 0x00000000004abe54 in slapauth (argc=<optimized out>, argv=0x7fffffffdcc8) at slapauth.c:161 #7 0x0000000000425e98 in main (argc=7, argv=0x7fffffffdc98) at main.c:664 Note that there is no bug if one of this condition is true: * overlay ppolicy is not configured * olcAuthRegexp does not use internal LDAP search * GSSAPI schema is not requested in slapauth Hope you have enough information in this report. Feel free to ask more if needed.

1 0

Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by ondra＠mistotebe.net 30 Mar '17

30 Mar '17

On Tue, Sep 22, 2015 at 08:45:12PM +0000, ondra(a)mistotebe.net wrote: > On Tue, Sep 22, 2015 at 09:01:59AM +0000, geert(a)hendrickx.be wrote: >> For clarity I do agree that a control should exist to bypass uniqueness >> (and other) constraints. However I think manageDSAit is not the >> appropriate control by its definition, and also in practice given the >> fact it's set per default by popular client libs. >> >> Relax Rules seems much more appropriate for this use case, as it's intended >> to temporarily relax database constraints, for administrative use only. > > Yes, Relax control is better for manual bypass. We just need to make > sure the original issue that this code was created to address is not > reintroduced. ITS#6641 was put up to allow replication to bypass this > overlay and anything that was already loaded to one master should > happily replicate everywhere else. At that point, manageDSAit was the > only way I could find to distinguish an operation coming from syncrepl, > it seems that the constraint overlay has a more reliable check so that > might be a better idea. > > Patch to that effect is here: > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150922-ITS-8245-unique-rela… Given that relax control is still allowed for everyone (and no ACL support for controls exists yet), this patch will buy us little. I have updated the test suite accordingly so that this can be merged when OpenLDAP is ready: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170330-ITS-8245-unique-rela… -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

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