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
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 |