I think I can agree with 1-8, 9 is one solution to fix the problem you
reported, but not yet validate that there are no other side effects,
there are potential postop plugins which should NOT be called for
tombstone delete, eg retro cl, we need to investigate side effects of
the patch and evaluate other solutions, I suggested one in anotehr reply.
for 10, the claim that not crying hurrah and merging a patch without
further investigation and testing is "doctrinal objection" is very
strong and I have to reject this.
Regards,
Ludwig
On 02/04/2020 05:00 PM, Jay Fenlason wrote:
Ok, let's take this from the top:
1: Defects that cause a server to become unresponsive are bad and must
be repaired as soon as possible.
2: Some #1 class defects are exploitable and require a CVE. As far as
I can tell, this one does not, but you should keep an eye out for the
possibility.
3: The #1 class defect I have found can be triggered in at least two
ways. One requires ipa-replica-install and is hard to reproduce in a
test environment. The other requires ldapdelete and is easy to
reproduce in an isolated VM.
4: The defect is a mismatch between the plugin ABI as implemented by
389-ds, and the behavior the NIS plugin expects.
5: I have found no specification or documentation on said ABI, so I
can only guess what the correct behavior is here.
6: The ABI includes two functions in the plugin: pre_delete and
post_delete.
7: The NIS plugin expects that every call to pre_delete will be
followed by a call to post_delete. It takes a lock in pre_delete and
releases it in post_delete.
8: Under some circumstances 389-ds can call pre_delete but fail to
call post_delete. Because of #5, there is no way to tell if this is
expected behavior, but the NIS plugin clearly does not expect it.
9: My patch ensures that every call to pre_delete is followed by a
corresponding call to post_delete. V1 of the patch also ensures that
every call to post_delete is after a corresponding pre_delete call.
V2 relaxes the second requirement, allowing post_delete calls without
a corresponding pre_delete call because someone expressed worry about
potential regressions.
10: You are refusing to merge my patch because of a doctrinal
objection to the use of ldapdelete in the simple reproducer.
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
--
Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243,
Geschäftsführer: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
