Re: Multi-tenancy with RLS
От | Tom Lane |
---|---|
Тема | Re: Multi-tenancy with RLS |
Дата | |
Msg-id | 21902.1455052932@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Multi-tenancy with RLS (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: Multi-tenancy with RLS
Re: Multi-tenancy with RLS Re: Multi-tenancy with RLS |
Список | pgsql-hackers |
Joe Conway <mail@joeconway.com> writes: > Personally I don't buy that the current situation is a good thing. I > know that the "ship has sailed" and regret not having participated in > the earlier discussions, but I agree with JD here -- the unprivileged > user should not have to even think about whether RLS exists, they should > only see what they have been allowed to see by the privileged users (and > in the context of their own objects, owners are privileged). I don't > think an unprivileged user should get to decide what code runs in order > to make that happen. Part of the problem here is that we have *not* created any hard and fast distinction between "privileged" and "unprivileged" users; I think that even speaking in those terms about RLS risks errors in your thinking. In particular, the code-execution issue arises from the fact that a table owner can now cause code to execute *with the permissions of someone else* if the someone else is foolish enough to select from his table. No special privileges required, just the ability to create a table. If we make pg_dump run with RLS enabled, then the "foolish" part doesn't need to be any more foolish than forgetting a -t switch when using pg_dump. Maybe we need to restrict that somehow, or maybe some better solution exists that we've not thought of yet. But in its current state, RLS is at least as much a security hazard as it is a security aid. I do not want to see it extended in ways that make pg_dump unsafe to use. regards, tom lane
В списке pgsql-hackers по дате отправления: