Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com
On Thu, Mar 30, 2017 at 12:30:09PM -0700, Paul B. Henson wrote:
>> From: Ond=C5=99ej Kuzn=C3=ADk
>> 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?
>=20
> There aren't currently any entries like that in the log, although the l=
ast
> crash was a week or two ago. I will check again right after the next cr=
ash.
> 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:
>=20
> [...]
>=20
> And it does not appear to have that signature.
Hi Paul,
"modify: replace" entries should result in modify_replace_values being
called instead, where modify_add_values is called when the mod is
LDAP_MOD_ADD (set up from reqMod values starting "attr:+").
Not sure if there is a way to reset the LDAPResult *msg in
syncrepl_message_to_op to retrieve the entry from there but that would
be the place I'd look when you get a another crash.
Regards,
--=20
Ond=C5=99ej Kuzn=C3=ADk
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
6 years, 6 months
RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org
> From: Quanah Gibson-Mount
> Sent: Thursday, March 30, 2017 5:16 PM
>
> 2.4.44+ITS8432. ;) So I think there's something specific to your use case
> (the hardest kinds to track down!).
* Specific to my use case - check
* Not reproducible - check
* Only occurs sporadically at randomly dispersed intervals - check
Perhaps we've hit a heisenbug ;). I was kind of hoping it would get fixed by
accident by other updates in the next release :).
6 years, 6 months
RE: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com
--On Friday, March 31, 2017 1:05 AM +0000 henson(a)acm.org wrote:
>> From: Quanah Gibson-Mount
>> Sent: Thursday, March 30, 2017 3:14 PM
>>
>> 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.
>
> Hmm, I started seeing this problem when I upgraded from 2.4.43 to
> 2.4.44+ITS 8432 patch. I've never run stock 2.4.44; so I can't say
> whether this issue would occur without the ITS 8432 patch...
Either way, it's a significant regression that needs fixing before I'd be
comforable with a 2.4.45 release. Interestingly, I never saw this problem
@ Zimbra, even though it is constantly modifying data and has
2.4.44+ITS8432. ;) So I think there's something specific to your use case
(the hardest kinds to track down!).
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 6 months
RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org
> From: Quanah Gibson-Mount
> Sent: Thursday, March 30, 2017 3:14 PM
>
> 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.
Hmm, I started seeing this problem when I upgraded from 2.4.43 to 2.4.44+ITS
8432 patch. I've never run stock 2.4.44; so I can't say whether this issue
would occur without the ITS 8432 patch...
6 years, 6 months
RE: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com
--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>
6 years, 6 months
Re: (ITS#8626) TLS trace: SSL3 alert write:fatal:certificate unknown
by quanah＠symas.com
--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>
6 years, 6 months
Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by michael＠stroeder.com
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.
6 years, 6 months
Re: (ITS#8245) slapo-unique constraints bypassed by manageDsaIt, change to relax?
by ondra＠mistotebe.net
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
6 years, 6 months
RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org
> 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.
6 years, 6 months
