Re: Row-level Security vs Application-level authz - Mailing list pgsql-general

From Stephen Frost
Subject Re: Row-level Security vs Application-level authz
Date
Msg-id 20150224200711.GO29780@tamriel.snowman.net
Whole thread Raw
In response to Re: Row-level Security vs Application-level authz  (David Steele <david@pgmasters.net>)
Responses Re: Row-level Security vs Application-level authz  (David Steele <david@pgmasters.net>)
List pgsql-general
* David Steele (david@pgmasters.net) wrote:
> On 2/23/15 8:16 PM, Stephen Frost wrote:
> > * David G. Johnston (david.g.johnston@gmail.com) wrote:
> >> I take it that the table has to be permanent otherwise you would have
> >> suggested
> >> and unlogged temporary table as the target...
> >
> > A temporary table would have to be recreated each time and that'd be
> > less than ideal.  You can use a single unlogged table which includes the
> > backend pid (which can be acquired through a function call) to keep
> > track of which user is logged in on a given backend at a given point in
> > time.
>
> It's not clear to me why creating a temp table per session would be less
> than ideal.  I've certainly used session-scope temp tables to good
> effect a number of times.  Transaction-scope would be another story of
> course.
>
> Am I missing something?

The problem with a temporary table is, well, it goes away. :)  There are
further concerns that, because it's created in some fashion by the
single application user, it might be less secure.  Really, though, I'd
want it to be real so that it could have constraints be on it which
reference other appropriate tables, so the web user doesn't have to have
rights in any fashion to create objects, and so that it can be
referenced from RLS policies.  A table as transient as a temporary table
doesn't strike me as the right solution for that.

    Thanks!

        Stephen

Attachment

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re:
Next
From: David Steele
Date:
Subject: Re: Row-level Security vs Application-level authz