Re: RLS Design
От | Robert Haas |
---|---|
Тема | Re: RLS Design |
Дата | |
Msg-id | CA+TgmobOH+BvqmntaRFN5G+jZeZ2HUDAWDy42bMfRSRcKaroyg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RLS Design (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: RLS Design
|
Список | pgsql-hackers |
On Tue, Jul 1, 2014 at 3:33 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > An annoying complication, however, is how this interacts with column > privileges. Right now "GRANT SELECT(col1) ON t1 TO role1" gives role1 > access to every row in col1, and I think that has to remain the case, > since GRANTs only ever give you more access. But that leads to a > situation where the RLS quals applied would depend on the columns > selected. Wow, that seems pretty horrible to me. That means that if I do: SELECT a FROM tab; and then: SELECT a, b FROM tab; ...the second one might return fewer rows than the first one. I think there's a good argument that RLS is unlike other grantable privileges, and that it really ought to be defined as something which is imposed rather than a kind of access grant. If RLS is merely a modifier to an access grant, then every access grant has to make sure to include that modifier, or you have a security hole. But if it's a separate constrain on access, then you just do it once, and exempt people from it only as needed. That seems less error-prone to me -- it's sort of a default-deny policy, which is generally viewed as good for security -- and it avoids weird cases like the above, which I think could easily break application logic. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: