Re: row_security GUC, BYPASSRLS
От | Joe Conway |
---|---|
Тема | Re: row_security GUC, BYPASSRLS |
Дата | |
Msg-id | 55F84736.5080909@joeconway.com обсуждение исходный текст |
Ответ на | Re: row_security GUC, BYPASSRLS (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 09/15/2015 11:10 AM, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch <noah@leadboat.com> wrote: >>> It also requires a DBA unwilling to >>> furnish test accounts to custodians of sensitive data. With or without >>> row_security=force, such a team is on the outer perimeter of the audience able >>> to benefit from RLS. Nonetheless, I'd welcome a replacement test aid. > >> I can't argue with that, I suppose, but I think row_security=force is >> a pretty useful convenience. If we must remove it, so be it, but I'd >> be a little sad. > > Keep in mind that if you have an uncooperative DBA on your production > system, you can always test your policy to your heart's content on a > playpen installation. In fact, most people would consider that good > engineering practice anyway, rather than pushing untested code directly > into production. That's exactly right. We should provide flexibility for testing in test environments, and also the ability to lock things down tight in production. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
В списке pgsql-hackers по дате отправления: