Bug #118046 KILL (QUERY) should check thread ownership against the security context that initiated the current operation
Submitted: 23 Apr 21:21 Modified: 24 Apr 6:29
Reporter: Troels Madsen Email Updates:
Status: Analyzing Impact on me:
None 
Category:MySQL Server: Parser Severity:S2 (Serious)
Version:8.0 OS:Any
Assigned to: MySQL Verification Team CPU Architecture:Any

[23 Apr 21:21] Troels Madsen
Description:
Presently the permission to kill a query / connection is done against the current security context.
But when executing e.g. a stored procedure executing under a different user, this check will fail. This means you can't kill your own queries in this (typical) scenario.
Most client side libraries has includes the ability to specify a query timeout, and if the query timeout is exceeded, the client side library will typically try to kill the long running query. But if the thread is executing a stored procedure running under a different user, the attempt to cleanup will fail.
As a result the client side will have abandoned waiting for the result, but the long running query continues burning resources on the server!

How to repeat:
Create a long running (e.g. doing a sleep) stored procedure using security definer, with user B as definer.
Grant user A execute right on the stored procedure.
Start two connections as user A.
Call the stored procedure from the first connection.
Identify the running thread and try to kill it using KILL QUERY from the second connection.

Suggested fix:
In sql_parse.cc, method kill_one_thread, line 6467, change from
    if (sctx->check_access(SUPER_ACL) ||
        sctx->has_global_grant(STRING_WITH_LEN("CONNECTION_ADMIN")).first ||
        sctx->user_matches(tmp->security_context())) {
to
    if (sctx->check_access(SUPER_ACL) ||
        sctx->has_global_grant(STRING_WITH_LEN("CONNECTION_ADMIN")).first ||
        sctx->user_matches(&(tmp->m_main_security_ctx))) {

(( preferably with a new getter method for &(tmp->m_main_security_ctx) ))