Re: Multi-tenancy with RLS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Multi-tenancy with RLS
Date
Msg-id 21902.1455052932@sss.pgh.pa.us
Whole thread Raw
In response to Re: Multi-tenancy with RLS  (Joe Conway <mail@joeconway.com>)
Responses Re: Multi-tenancy with RLS
Re: Multi-tenancy with RLS
Re: Multi-tenancy with RLS
List pgsql-hackers
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.

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.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Multi-tenancy with RLS
Next
From: Stephen Frost
Date:
Subject: Re: Multi-tenancy with RLS