Issue 6157 - unAbandonable operations aren't.
Summary: unAbandonable operations aren't.
Status: RESOLVED PARTIAL
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-01 13:55 UTC by Hallvard Furuseth
Modified: 2020-03-19 15:29 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Hallvard Furuseth 2009-06-01 13:55:37 UTC
Full_Name: Hallvard B Furuseth
Version: HEAD
OS: Linux
URL: 
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard


RFCs 3909 (Cancel) and 4511 (LDAP protocol) say some operations cannot
be cancelled/abandoned:  Abandon, Bind, Unbind, StartTLS, Cancel.

Clients can cancel least Cancel.  That lets a client deadlock slapd, or
all slapd threads but one, by spamming slapd with pairs of Cancels that
cancel each other.  If both are started, each waits for the other.
Also cn=config operations need to be at least unCancelable: The same
happens if you send pairs of (cn=config op, Cancel that op).

Regarding Cancel, one fix resembling current code would be:
* Before an operation waits for (an)other operation(s):
  - Fail if o_cancel, and if o_abandon when the op is abandonable,
  - Make it uncancellable: set o_cancel = tooLate even when !o_abandon.
* Cancel and Abandon operations:
  - Fail if the targeted operation already has tooLate/cannotCancel.
    Actually Cancel already does, but with wrong result code + message.

    I include Abandon to keep the number of cancel/abandon-related
    states down.  Also, (o_abandon, o_cancel) = (1, tooLate) would
    otherwise mean two things with the fix above: The op was Cancelled
    but completed anyway, or the op was Abandoned and is uncancellable
    (but not necessarily unabandonable).
Comment 1 Hallvard Furuseth 2009-06-01 13:56:50 UTC
moved from Incoming to Software Bugs
Comment 2 Hallvard Furuseth 2009-06-03 13:21:02 UTC
Suggested partual fix - add this possible value for o_cancel:
    #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */

Something like this:
    http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt

Does not reject abandon(Cancel/StartTLS), would need to extend o_cancel
with yet another value.  That's ugly enough already, so I let that wait.
connection_abandon() in particular isn't invalid client action, but it
shouldn't be worse than causing a surprising result code or not response
before closing the connection.

Does not address syncprov's Cancel handler.

I don't know if the bconfig.c pathces are correct, but need to reject
cancel before (reacting to) thread pool pauses there and maybe in
syncrepl/syncprov.

-- 
Hallvard

Comment 3 Hallvard Furuseth 2009-06-03 15:04:23 UTC
changed notes
Comment 4 Hallvard Furuseth 2009-06-04 19:18:40 UTC
changed notes
changed state Open to Test
Comment 5 Hallvard Furuseth 2009-06-04 19:58:46 UTC
Caught cancel(cancel) and cancel/abandon(abandon/bind/unbind),
partly fixed cancel(cn=config update) problem, without doing this:

> Suggested partual fix - add this possible value for o_cancel:
>     #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */

Still need something that to fix cancel(cn=config update) completely.

syncrepl/syncprov, starttls not yet addressed.

Also cancel(cancel) still behaves in a non-RFC way.  Correct fix
would require resetting o_abandon, which seems unsafe.  Who knows
what has already reacted to it.


Will update this patch for the remaining issues later:

> Something like this:
>     http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt

-- 
Hallvard

Comment 6 Quanah Gibson-Mount 2009-06-04 23:18:19 UTC
changed notes
changed state Test to Partial
Comment 7 OpenLDAP project 2014-08-01 21:04:22 UTC
Some fixes in HEAD. See also ITS#6138
Some fixes in RE24. See also ITS#6138