| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: row_security GUC, BYPASSRLS |
| Date: | 2015-09-15 18:26:29 |
| Message-ID: | 55F862D5.2060103@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 09/15/2015 12:53 PM, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>> There are use cases where row_security=force will be set in production
>> environments, not only in testing.
>
> What cases, exactly, and is there another way to solve those problems?
> I concur with Noah's feeling that allowing security behavior to depend on
> a GUC is risky.
There are environments where there is a strong desire to use RLS to
control access in production, even for table owners and superusers.
Obviously there are more steps needed to completely achieve this level
of control, but removing the ability to force row security is going in
the wrong direction. Noah's suggestion of using a per table attribute
would work -- in fact I like the idea of that better than using the
current GUC.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2015-09-15 18:36:34 | Re: One question about security label command |
| Previous Message | Tom Lane | 2015-09-15 17:53:04 | Re: row_security GUC, BYPASSRLS |