Re: Multi-tenancy with RLS
От | Joshua D. Drake |
---|---|
Тема | Re: Multi-tenancy with RLS |
Дата | |
Msg-id | 56BA4A22.4010002@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Multi-tenancy with RLS (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Multi-tenancy with RLS
|
Список | pgsql-hackers |
On 02/09/2016 12:05 PM, Robert Haas wrote: > That's true. But I should also have an expectation that running > pg_dump won't trigger arbitrary code execution, which is why by > default, pg_dump sets row_security to OFF. That way, if a row > security policy applies, I get an error rather than an incomplete, > possibly-invalid dump (and arbitrary code execution on the server > side). If I'm OK with doing the dump subject to row security, I can > rerun with --enable-row-security. But this proposal would force > non-superusers to always use that option, and that's not a good idea. > If I understand correctly what we are talking about here is: 1. If RLS is enabled and a non-super user issues a pg_dump, it will error unless I issue --enable-row-security 2. If RLS is not enabled and a non-super user issues a pg_dump the behavior is basically what it is now. 3. If RLS is enabled or not and I am a super user, it doesn't matter either way. From my perspective, I should not have to enable row security as a non-super user to take a pg_dump. It should just work for what I am allowed to see. In other words: pg_dump -U $non-super_user Should just work, period. Sincerely, Joshua D. Drake -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
В списке pgsql-hackers по дате отправления: