RLS restrictive hook policies

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема RLS restrictive hook policies
Дата
Msg-id CAEZATCW6oAnCoBhq6JBV5cp3cMstNaD2tSEFZWMq4BqS-NOS+A@mail.gmail.com
обсуждение исходный текст
Ответы Re: RLS restrictive hook policies  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
In get_row_security_policies():
   /*    * If the only built-in policy is the default-deny one, and hook policies    * exist, then use the hook
policiesonly and do not apply the    * default-deny policy.  Otherwise, we will apply both sets below.    */   if
(defaultDeny&&       (hook_policies_restrictive != NIL || hook_policies_permissive != NIL))   {       rowsec_expr =
NULL;      rowsec_with_check_expr = NULL;   }
 

So if the only policies that exist are restrictive policies from an
extension, the default-deny policy is not applied and the restrictive
policies are applied instead, which is effectively a "default-allow"
situation with each restrictive policy further limiting access to the
table.

I think this is potentially very dangerous when both kinds of policy
exist. Consider for example a situation where initially multiple
permissive policies are set up for different users allowing them
access to different subsets of the table, and users not covered by any
of those permissive policies have no access. Then suppose that later a
restrictive policy is added, applying to all users -- the intention
being to prevent any user from accessing some particularly sensitive
data. The result of adding that restrictive policy would be that all
the users who previously had no access at all would suddenly have
access to everything not prohibited by the restrictive policy.

That goes against everything I would expect from a restrictive policy
-- adding more restrictive policies should only ever reduce the number
of rows visible, not ever open up more. So I think the test above
should only disable the default-deny policy if there are any
permissive policies from the extension.

Of course that will make life a little harder for people who only want
to use restrictive policies, since they will be forced to first add a
permissive policy, possibly just one that's always true, but I think
it's the safest approach.

Possibly if/when we add proper SQL support for defining restrictive
policies, we might also add an option to ALTER TABLE ... ENABLE ROW
LEVEL SECURITY to allow a table to have RLS enabled in default-allow
mode, for users who know they only want to add restrictive policies.
However, I think that should be something the user has to explicitly
ask for, not an automatic decision based on the existence of
restrictive policies.

Thoughts?

Regards,
Dean



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Transactions involving multiple postgres foreign servers
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: pg_rewind failure by file deletion in source server