Re: Row-security on updatable s.b. views

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(at)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(at)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(at)entry=0x8b7bf0 "!(!bms_is_empty(upper_varnos))",
> errorType=errorType(at)entry=0x78e89c "FailedAssertion", fileName=fileName(at)entry=0x8b78d7 "subselect.c", lineNumber=lineNumber(at)entry=1394) at assert.c:54
> #3 0x000000000061de2b in convert_EXISTS_sublink_to_join (root=<optimized out>, sublink=<optimized out>, under_not=under_not(at)entry=0 '\000', available_rels=0x117d038)
> at subselect.c:1394
> #4 0x000000000061efa9 in pull_up_sublinks_qual_recurse (root=root(at)entry=0x117d058, node=0x117a0f8, jtlink1=jtlink1(at)entry=0x7fff6d97f708,
> available_rels1=available_rels1(at)entry=0x117d038, jtlink2=jtlink2(at)entry=0x0, available_rels2=available_rels2(at)entry=0x0) at prepjointree.c:391
> #5 0x000000000061f339 in pull_up_sublinks_jointree_recurse (root=root(at)entry=0x117d058, jtnode=0x117a040, relids=relids(at)entry=0x7fff6d97f758) at prepjointree.c:208
> #6 0x000000000062066f in pull_up_sublinks (root=root(at)entry=0x117d058) at prepjointree.c:147
> #7 0x000000000061967e in subquery_planner (glob=0x10c3fb8, parse=parse(at)entry=0x1179af8, parent_root=parent_root(at)entry=0x1182fd0, hasRecursion=hasRecursion(at)entry=0 '\000',
`
> #8 0x00000000005fc093 in set_subquery_pathlist (root=root(at)entry=0x1182fd0, rel=rel(at)entry=0x1179370, rti=rti(at)entry=4, rte=rte(at)entry=0x1183980) at allpaths.c:1209
> #9 0x00000000005fc54e in set_rel_size (root=root(at)entry=0x1182fd0, rel=0x1179370, rti=rti(at)entry=4, rte=0x1183980) at allpaths.c:265
> #10 0x00000000005fc62e in set_base_rel_sizes (root=root(at)entry=0x1182fd0) at allpaths.c:180
> #11 0x00000000005fd584 in make_one_rel (root=root(at)entry=0x1182fd0, joinlist=joinlist(at)entry=0x1179560) at allpaths.c:138
> #12 0x000000000061617a in query_planner (root=root(at)entry=0x1182fd0, tlist=tlist(at)entry=0x11771c8, qp_callback=qp_callback(at)entry=0x616fd6 <standard_qp_callback>,
> qp_extra=qp_extra(at)entry=0x7fff6d97fa00) at planmain.c:236
> #13 0x00000000006182f2 in grouping_planner (root=root(at)entry=0x1182fd0, tuple_fraction=tuple_fraction(at)entry=0) at planner.c:1280
> #14 0x0000000000619a11 in subquery_planner (glob=glob(at)entry=0x10c3fb8, parse=parse(at)entry=0x10c3d30, parent_root=parent_root(at)entry=0x0,
> hasRecursion=hasRecursion(at)entry=0 '\000', tuple_fraction=0, subroot=subroot(at)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(at)entry=0x10c3d30, cursorOptions=cursorOptions(at)entry=0, boundParams=boundParams(at)entry=0x0) at planner.c:139
> #17 0x000000000068c64b in pg_plan_query (querytree=0x10c3d30, cursorOptions=cursorOptions(at)entry=0, boundParams=boundParams(at)entry=0x0) at postgres.c:759
> #18 0x000000000068c6d3 in pg_plan_queries (querytrees=<optimized out>, cursorOptions=cursorOptions(at)entry=0, boundParams=boundParams(at)entry=0x0) at postgres.c:818
> #19 0x000000000068c932 in exec_simple_query (query_string=query_string(at)entry=0x10c2d78 "SELECT * FROM hl7.test;") at postgres.c:983
> #20 0x000000000068e46e in PostgresMain (argc=<optimized out>, argv=argv(at)entry=0x10cd1f0, dbname=0x10cd058 "regress", username=<optimized out>) at postgres.c:4003
> #21 0x00000000006419a7 in BackendRun (port=port(at)entry=0x10c7e50) at postmaster.c:4080
> #22 0x00000000006432c2 in BackendStartup (port=port(at)entry=0x10c7e50) at postmaster.c:3769
> #23 0x0000000000643526 in ServerLoop () at postmaster.c:1580
> #24 0x000000000064467c in PostmasterMain (argc=argc(at)entry=4, argv=argv(at)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