Re: API change advice: Passing plan invalidation info from the rewriter into the planner? - Mailing list pgsql-hackers

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Jun 12, 2014 at 8:13 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > This approach was suggested by an existing user testing out this RLS
> > approach, to be fair, but it looks pretty sane to me as a way to address
> > some of these concerns. Certainly open to other ideas and thoughts though.
>
> In general, I agree that this is a good approach.  I think it will be
> difficult to have a GUC with three values, one of which is
> superuser-only and the other two of which are not.  I don't think
> there's any precedent for something like that in the existing
> framework, and I think it's likely we'll run into unpleasant corner
> cases if we try to graft it in.  Also, I think we need to separate
> things: whether the system is willing to allow the user to access the
> table without RLS, and whether the user is willing to accept RLS if
> the system deems it necessary.

Good point- I agree that it's best to avoid having to support individual
superuser-only only options on a GUC.  Also, addressing the issues
independently also makes sense to me.

> For the first one, two solutions have been proposed.  The initial
> proposal was to insist on RLS except for the superuser (and maybe the
> table owner?).  Having a separate grantable privilege, as Dean
> suggests, may be better.  I'll reply separately to that email also, as
> I have a question about what he's proposing.

I like the idea of a grantable privilege as it allows the granularity
that some users may require (or be frustrated that we don't have it).

> For the second one, I think the two most useful behaviors are "normal
> mode" - i.e. allow access to the table, applying RLS predicates if
> required and not applying them if I am exempt - and "error-instead"
> mode - i.e. if my access to this table would be mediated by an RLS
> predicate, then throw an error instead.

Right, makes sense.

> There's a third mode which
> might be useful as well, which is "even though I have the *right* to
> bypass the RLS predicate on this table, please apply the predicate
> anyway".  This could be used by the table owner in testing, for
> example.

Agreed, this sounds very useful too.

> Here again, the level of granularity we want to provide is
> an interesting question.  Having a GUC (e.g. enable_row_level_security
> = on, off, force) would be adequate for pg_dump, but allowing the
> table name to be qualified in the query, as proposed downthread, would
> be more granular, admittedly at some parser cost.  I'm personally of
> the view that we *at least* need the GUC, because that seems like the
> best way to secure pg_dump, and perhaps other applications.  We can
> and should give pg_dump an--allow-row-level-security flag, I think,
> but pg_dump's default behavior should be to configure the system in
> such a way that the dump will fail rather than complete with a subset
> of the data.

This sounds good to me.

> I'm less sure whether we should have something that can
> be used to qualify table names in particular queries.  I think it
> would be really useful, but I'm concerned that it will require
> creating additional fully-reserved keywords, which are somewhat
> painful for users.

I've been trying to think of the use-case for this.  It certainly
*sounds* nice, but on reflection, the use-case for this seems to me to
be that you're trying to develop some application which will be
constrained by RLS totally and therefore want to flip back-and-forth
between "RLS on" and "RLS off" (for the tables involved).  When would
you really need, in the same query, to have RLS enabled for table X but
disabled for table Y?  I do like the idea of an *independent* option to
(just) COPY which says "give me all the data or error, independent of
the GUC for the same purpose".  Would be curious to hear what others
think of that proposal.
Thanks,
    Stephen