Re: Multi-tenancy with RLS

Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Joe Conway <mail@joeconway.com> writes:
> > Personally I don't buy that the current situation is a good thing. I
> > know that the "ship has sailed" and regret not having participated in
> > the earlier discussions, but I agree with JD here -- the unprivileged
> > user should not have to even think about whether RLS exists, they should
> > only see what they have been allowed to see by the privileged users (and
> > in the context of their own objects, owners are privileged). I don't
> > think an unprivileged user should get to decide what code runs in order
> > to make that happen.
>
> Part of the problem here is that we have *not* created any hard and fast
> distinction between "privileged" and "unprivileged" users; I think that
> even speaking in those terms about RLS risks errors in your thinking.

I agree that where, exactly, that line is drawn is part of the issue,
and where's it's drawn is really system-dependent.  In many
environments, I view Joe's comments as entirely accurate- only
privileged users are allowed to create objects *at all*.  Of course,
there are a lot of environments where everyone is allowed to create
objects and, in those environments, all those users would be viewed as
"unprivileged", generally speaking.

> In particular, the code-execution issue arises from the fact that a table
> owner can now cause code to execute *with the permissions of someone else*
> if the someone else is foolish enough to select from his table.  No
> special privileges required, just the ability to create a table.  If we
> make pg_dump run with RLS enabled, then the "foolish" part doesn't need to
> be any more foolish than forgetting a -t switch when using pg_dump.

That distinction is really only relevant when it comes to pg_dump, as
those same users could use views to cause their code to be executed by
other users who are selecting from their view, and they could change if
it's a table or a view quite easily.  From a practical standpoint, we're
making a huge distinction between our client tools- pg_dump must be
protected from X, but we don't have any such qualms or concerns
regarding queries sent from psql.

Perhaps that's the right distinction to make, or perhaps we should come
up with a better answer for psql than what we have now, but I don't
agree that RLS is seriously moving the goalposts, overall, here,
particularly since you're not going to have any RLS policies being
executed by pg_dump when run as a superuser anyway, given Noah's change
to how BYPASSRLS works.

> Maybe we need to restrict that somehow, or maybe some better solution
> exists that we've not thought of yet.  But in its current state, RLS
> is at least as much a security hazard as it is a security aid.
> I do not want to see it extended in ways that make pg_dump unsafe to
> use.

I'm not against coming up with an approach which restricts cases where
user A can write code that will be run under another user's rights,
provided it doesn't make the system overly painful to use.  I don't see
RLS as changing the security risks all that much when you're talking
about regular user queries through psql, and the concern regarding
pg_dump has been addressed through the default of row_security being
off.

Thanks!

Stephen