From 01ba7894f3f72ea57d1cfdc4f40f6231bc6cd9cd Mon Sep 17 00:00:00 2001 From: Noah Misch Date: Sat, 3 Oct 2015 20:19:57 -0400 Subject: Make BYPASSRLS behave like superuser RLS bypass. Specifically, make its effect independent from the row_security GUC, and make it affect permission checks pertinent to views the BYPASSRLS role owns. The row_security GUC thereby ceases to change successful-query behavior; it can only make a query fail with an error. Back-patch to 9.5, where BYPASSRLS was introduced. --- doc/src/sgml/ref/create_role.sgml | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) (limited to 'doc/src/sgml/ref') diff --git a/doc/src/sgml/ref/create_role.sgml b/doc/src/sgml/ref/create_role.sgml index f4a176bff3f..240c21ce85f 100644 --- a/doc/src/sgml/ref/create_role.sgml +++ b/doc/src/sgml/ref/create_role.sgml @@ -196,16 +196,13 @@ CREATE ROLE name [ [ WITH ] NOBYPASSRLS - These clauses determine whether a role is allowed to bypass row-level security (RLS) - policies. A role having the BYPASSRLS attribute will - be allowed to bypass row-security policies by setting - row_security to - OFF. NOBYPASSRLS is the default. + These clauses determine whether a role bypasses every row-level + security (RLS) policy. NOBYPASSRLS is the default. Note that pg_dump will set row_security to OFF by default, to ensure all contents of a table are dumped out. If the user running pg_dump does not have appropriate permissions, an error will be returned. The superuser and owner of the - table being dumped are considered to always have the right to bypass RLS. + table being dumped always bypass RLS. -- cgit v1.2.3