Re: Multi-tenancy with RLS

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joe Conway <mail(at)joeconway(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Multi-tenancy with RLS
Date: 2016-02-09 19:47:46
Message-ID: CA+TgmoYj8P9vzX-JfMqQJY_jmdjt4+juSaV=6sNdYeCxr5kuXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost <sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2016-02-09 19:55:32 Re: proposal: schema PL session variables
Previous Message Christian Ullrich 2016-02-09 19:32:27 Re: pl/pgSQL, get diagnostics and big data