Re: Feature: temporary materialized views

On 1/17/19 4:57 PM, Tom Lane wrote:
> Andreas Karlsson <andreas@proxel.se> writes:
>> On 1/11/19 8:47 PM, Mitar wrote:
>>>> Is it really ok to just remove SECURITY_RESTRICTED_OPERATION from
>>>> ExecCreateTableAs()?
> 
>>> The comment there said that this is not really necessary for security:
>>> "This is not necessary for security, but this keeps the behavior
>>> similar to REFRESH MATERIALIZED VIEW.  Otherwise, one could create a
>>> materialized view not possible to refresh."
> 
>> Hm, I am still not convinced just removing it is a good idea. Sure, it
>> is not a security issue but usability is also important.
> 
> Indeed.  I don't buy the argument that this should work differently
> for temp views.  The fact that they're only accessible in the current
> session is no excuse for that: security considerations still matter,
> because you can have different privilege contexts within a single
> session (consider SECURITY DEFINER functions etc).
> 
> What is the stumbling block to just leaving that alone?

I think the issue Mitar ran into is that the temporary materialized view 
is created in the rStartup callback of the receiver which happens after 
SECURITY_RESTRICTED_OPERATION is set in ExecCreateTableAs(), so the 
creation of the view itself is denied.

 From a cursory glance it looks like it would be possible to move the 
setting of SECURITY_RESTRICTED_OPERATION to inside the rStartup 
callabck, other than that the code for resetting the security context 
might get a bit ugly. Do you see any flaws with that solution?

Andreas