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

From Robert Haas
Subject Re: Multi-tenancy with RLS
Date
Msg-id CA+TgmoYj8P9vzX-JfMqQJY_jmdjt4+juSaV=6sNdYeCxr5kuXg@mail.gmail.com
Whole thread Raw
In response to Re: Multi-tenancy with RLS  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Multi-tenancy with RLS
Re: Multi-tenancy with RLS
List pgsql-hackers
On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> Whereupon you'd have no certainty that what you got represented a
>> complete dump of your own data.
>
> It would be a dump of what you're allowed to see, rather than an error
> saying you couldn't dump something you couldn't see, which is the
> alternative we're talking about here.  Even if you've got a dependency
> to something-or-other, if you don't have access to it, then you're
> going to get an error.

I think you're dismissing Tom's concerns far too lightly.  The
row_security=off mode, which is the default, becomes unusable for
non-superusers under this proposal.  That's bad.  And if you switch to
the other mode, then you might accidentally fail to get all of the
data in some table you're trying to back up.  That's bad too: that's
why it isn't the default.  There's a big difference between saying
"I'm OK with not dumping the tables I can't see" and "I'm OK with not
dumping all of the data in some table I *can* see".

It seems to me that there's a big difference between policies we ship
out of the box and policies that are created be users: specifically,
the former can be assumed benign, while the latter can't.  I think
that difference matters here, although I'm not sure exactly where to
go with it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Christian Ullrich
Date:
Subject: Re: pl/pgSQL, get diagnostics and big data
Next
From: "David G. Johnston"
Date:
Subject: Re: proposal: schema PL session variables