Failed assertion due to procedure created with SECURITY DEFINER option

From: amul sul <sulamul(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Failed assertion due to procedure created with SECURITY DEFINER option
Date: 2018-06-29 11:07:46
Message-ID: CAAJ_b942auDRKu22MW+yMxTnSyyAdEoGkUSt+H37-0HcCjdA0w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I am getting assertion failure in StartTransaction() on the latest
master when procedure having SECURITY DEFINER called, here is the
script to reproducible this crash:

--create procedure
CREATE PROCEDURE transaction_test1() LANGUAGE plpgsql SECURITY DEFINER
AS $$ BEGIN
COMMIT;
END $$;

-- calling this procedure will have the assertion
CALL transaction_test1();

This happens because of in fmgr_security_definer() function we are
changing global variable SecurityRestrictionContext and in the
StartTransaction() insisting it should be zero, which is the problem.

TWIW, here is the backtrace:

(gdb) bt 15
#0 0x00007f2db45fb277 in raise () from /lib64/libc.so.6
#1 0x00007f2db45fc968 in abort () from /lib64/libc.so.6
#2 0x0000000000a1f456 in ExceptionalCondition (conditionName=0xadf94f
"!(s->prevSecContext == 0)", errorType=0xadf467 "FailedAsse
rtion", fileName=0xadf460 "xact.c", lineNumber=1908) at assert.c:54
#3 0x0000000000542f98 in StartTransaction () at xact.c:1908
#4 0x0000000000543c54 in StartTransactionCommand () at xact.c:2684
#5 0x0000000000719509 in SPI_start_transaction () at spi.c:201
#6 0x00007f2da4a92315 in exec_stmt_commit (estate=0x7fffe04d3310,
stmt=0x2b69c68) at pl_exec.c:4723
#7 0x00007f2da4a8c893 in exec_stmt (estate=0x7fffe04d3310,
stmt=0x2b69c68) at pl_exec.c:2008
#8 0x00007f2da4a8c4f2 in exec_stmts (estate=0x7fffe04d3310,
stmts=0x2b69cb0) at pl_exec.c:1875
#9 0x00007f2da4a8c3a0 in exec_stmt_block (estate=0x7fffe04d3310,
block=0x2b69b08) at pl_exec.c:1816
#10 0x00007f2da4a89f61 in plpgsql_exec_function (func=0x2ac8d20,
fcinfo=0x7fffe04d3740, simple_eval_estate=0x0, atomic=false) at p
l_exec.c:586
#11 0x00007f2da4a847b0 in plpgsql_call_handler (fcinfo=0x7fffe04d3740)
at pl_handler.c:263
#12 0x0000000000a287c8 in fmgr_security_definer
(fcinfo=0x7fffe04d3740) at fmgr.c:748
#13 0x0000000000657fc1 in ExecuteCallStmt (stmt=0x2a981e8, params=0x0,
atomic=false, dest=0x2a98540) at functioncmds.c:2294
#14 0x00000000008b71b2 in standard_ProcessUtility (pstmt=0x2a982b8,
queryString=0x2a97698 "CALL transaction_test1();", context=PRO
CESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x2a98540,
completionTag=0x7fffe04d3f70 "") at utility.c:649
(More stack frames follow...)

Regards,
Amul Sul

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-06-29 11:52:23 Re: assert in nested SQL procedure call in current HEAD
Previous Message Thomas Munro 2018-06-29 10:28:50 Re: [HACKERS] SERIALIZABLE with parallel query