Re: Multi-tenancy with RLS
От | Robert Haas |
---|---|
Тема | Re: Multi-tenancy with RLS |
Дата | |
Msg-id | CA+TgmoYj8P9vzX-JfMqQJY_jmdjt4+juSaV=6sNdYeCxr5kuXg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Multi-tenancy with RLS (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Multi-tenancy with RLS
Re: Multi-tenancy with RLS |
Список | 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 по дате отправления: