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

On 13 February 2014 04:12, Craig Ringer <craig@2ndquadrant.com> wrote:
> 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.
>

I'm not sure how much further you've got with this, but I think the
issue is that the securityQuals that you're adding don't refer to the
correct RTE. When adding securityQuals to an RTE, they are expected to
have Vars whose varno matches the rt_index of the RTE (see for example
the code in rewriteTargetView() which calls ChangeVarNodes() on
viewqual before adding the qual to securityQuals or the main query
jointree). prepend_row_security_quals() doesn't appear to have any
similar code, and it would need to be passed the rt_index to do that.

Regards,
Dean