Re: [RFC] Interface of Row Level Security
От | Kohei KaiGai |
---|---|
Тема | Re: [RFC] Interface of Row Level Security |
Дата | |
Msg-id | CADyhKSWYWGfk7+s6Zc8CP_m37RwHJiE3VUEpPJ1D2ok6v64QaQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [RFC] Interface of Row Level Security (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [RFC] Interface of Row Level Security
Re: [RFC] Interface of Row Level Security |
Список | pgsql-hackers |
2012/5/29 Robert Haas <robertmhaas@gmail.com>: > One idea might be to have a grantable permission that permits the RLS > policy to be bypassed. So, if a user has only SELECT permission, they > can select from the table, but the RLS policy will apply. If they > have both SELECT and RLSBYPASS (probably not what we really want to > call it) permission, then they can select from the table and the RLS > policy will be skipped. This means that superusers automatically skip > all RLS policies (which seems right) and table owners skip them by > default (but could revoke their own privileges) and other people can > skip them if the table owner (or the superuser) grants them the > appropriate privilege on the table involved. > Isn't it unavailable to describe using RLS policy? In case when 'alice' and 'bob' should bypass RLS policy on a certain table, we will be able to describe it as follows: (current_user in ('alice', 'bob') OR rls_policy_this_table(X, Y, Z)) I have one concern the "current_user in (...)" is not wiped out at the planner stage, although its evaluation result is obvious prior to execution. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: