Re: Row-security on updatable s.b. views - Mailing list pgsql-hackers

On 02/11/2014 08:19 PM, Yeb Havinga wrote:

> I compared output of psql -ef of the minirim.sql script posted earlier
> in http://www.postgresql.org/message-id/52F54927.1040102@gmail.com
> between v4 and v7.
> 
> Not everything is ok.

> +psql:/home/m/minirim2.sql:409: ERROR:  attribute 6 has wrong type
> +DETAIL:  Table has type tsrange, but query expects _confidentialitycode.

This looks like an issue with attribute transformations made when
applying security barrier quals.

> +psql:/home/m/minirim2.sql:439: connection to server was lost

That's dying with:

> Program received signal SIGABRT, Aborted.
> 0x0000003f02c359e9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) bt
> #0  0x0000003f02c359e9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x0000003f02c370f8 in __GI_abort () at abort.c:90
> #2  0x0000000000758d9d in ExceptionalCondition (conditionName=conditionName@entry=0x8b7bf0
"!(!bms_is_empty(upper_varnos))",
 
>     errorType=errorType@entry=0x78e89c "FailedAssertion", fileName=fileName@entry=0x8b78d7 "subselect.c",
lineNumber=lineNumber@entry=1394)at assert.c:54
 
> #3  0x000000000061de2b in convert_EXISTS_sublink_to_join (root=<optimized out>, sublink=<optimized out>,
under_not=under_not@entry=0'\000', available_rels=0x117d038)
 
>     at subselect.c:1394
> #4  0x000000000061efa9 in pull_up_sublinks_qual_recurse (root=root@entry=0x117d058, node=0x117a0f8,
jtlink1=jtlink1@entry=0x7fff6d97f708,
 
>     available_rels1=available_rels1@entry=0x117d038, jtlink2=jtlink2@entry=0x0,
available_rels2=available_rels2@entry=0x0)at prepjointree.c:391
 
> #5  0x000000000061f339 in pull_up_sublinks_jointree_recurse (root=root@entry=0x117d058, jtnode=0x117a040,
relids=relids@entry=0x7fff6d97f758)at prepjointree.c:208
 
> #6  0x000000000062066f in pull_up_sublinks (root=root@entry=0x117d058) at prepjointree.c:147
> #7  0x000000000061967e in subquery_planner (glob=0x10c3fb8, parse=parse@entry=0x1179af8,
parent_root=parent_root@entry=0x1182fd0,hasRecursion=hasRecursion@entry=0 '\000', `
 
> #8  0x00000000005fc093 in set_subquery_pathlist (root=root@entry=0x1182fd0, rel=rel@entry=0x1179370, rti=rti@entry=4,
rte=rte@entry=0x1183980)at allpaths.c:1209
 
> #9  0x00000000005fc54e in set_rel_size (root=root@entry=0x1182fd0, rel=0x1179370, rti=rti@entry=4, rte=0x1183980) at
allpaths.c:265
> #10 0x00000000005fc62e in set_base_rel_sizes (root=root@entry=0x1182fd0) at allpaths.c:180
> #11 0x00000000005fd584 in make_one_rel (root=root@entry=0x1182fd0, joinlist=joinlist@entry=0x1179560) at
allpaths.c:138
> #12 0x000000000061617a in query_planner (root=root@entry=0x1182fd0, tlist=tlist@entry=0x11771c8,
qp_callback=qp_callback@entry=0x616fd6<standard_qp_callback>, 
 
>     qp_extra=qp_extra@entry=0x7fff6d97fa00) at planmain.c:236
> #13 0x00000000006182f2 in grouping_planner (root=root@entry=0x1182fd0, tuple_fraction=tuple_fraction@entry=0) at
planner.c:1280
> #14 0x0000000000619a11 in subquery_planner (glob=glob@entry=0x10c3fb8, parse=parse@entry=0x10c3d30,
parent_root=parent_root@entry=0x0,
 
>     hasRecursion=hasRecursion@entry=0 '\000', tuple_fraction=0, subroot=subroot@entry=0x7fff6d97fb58) at
planner.c:574
> #15 0x0000000000619c1f in standard_planner (parse=0x10c3d30, cursorOptions=0, boundParams=0x0) at planner.c:211
> #16 0x0000000000619e35 in planner (parse=parse@entry=0x10c3d30, cursorOptions=cursorOptions@entry=0,
boundParams=boundParams@entry=0x0)at planner.c:139
 
> #17 0x000000000068c64b in pg_plan_query (querytree=0x10c3d30, cursorOptions=cursorOptions@entry=0,
boundParams=boundParams@entry=0x0)at postgres.c:759
 
> #18 0x000000000068c6d3 in pg_plan_queries (querytrees=<optimized out>, cursorOptions=cursorOptions@entry=0,
boundParams=boundParams@entry=0x0)at postgres.c:818
 
> #19 0x000000000068c932 in exec_simple_query (query_string=query_string@entry=0x10c2d78 "SELECT * FROM hl7.test;") at
postgres.c:983
> #20 0x000000000068e46e in PostgresMain (argc=<optimized out>, argv=argv@entry=0x10cd1f0, dbname=0x10cd058 "regress",
username=<optimizedout>) at postgres.c:4003
 
> #21 0x00000000006419a7 in BackendRun (port=port@entry=0x10c7e50) at postmaster.c:4080
> #22 0x00000000006432c2 in BackendStartup (port=port@entry=0x10c7e50) at postmaster.c:3769
> #23 0x0000000000643526 in ServerLoop () at postmaster.c:1580
> #24 0x000000000064467c in PostmasterMain (argc=argc@entry=4, argv=argv@entry=0x10a8750) at postmaster.c:1235
> #25 0x00000000005d692c in main (argc=4, argv=0x10a8750) at main.c:205
> (gdb) 


It's crashing while pulling up the query over "emp" (hl7.employee) and
"part" (hl7.participation).

Given the simplicity of what the row-security code its self is doing,
I'm wondering if this is a case that isn't handled in updatable s.b.
views. I'll look into it.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services