database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

ALTER TABLE .. FORCE ROW LEVEL SECURITY

Browse Source 
To allow users to force RLS to always be applied, even for table owners,
add ALTER TABLE .. FORCE ROW LEVEL SECURITY.

row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump
output is complete (by default).

Also add SECURITY_NOFORCE_RLS context to avoid data corruption when
ALTER TABLE .. FORCE ROW SECURITY is being used. The
SECURITY_NOFORCE_RLS security context is used only during referential
integrity checks and is only considered in check_enable_rls() after we
have already checked that the current user is the owner of the relation
(which should always be the case during referential integrity checks).

Back-patch to 9.5 where RLS was added.
This commit is contained in:
Stephen Frost
2015-10-04 21:05:08 -04:00
parent 16a70e3059
commit 088c83363a
19 changed files with 537 additions and 64 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
src/backend/utils/init/miscinit.c
View File

@ -341,7 +341,7 @@ GetAuthenticatedUserId(void)
* GetUserIdAndSecContext/SetUserIdAndSecContext - get/set the current user ID
* and the SecurityRestrictionContext flags.
*
* Currently there are two valid bits in SecurityRestrictionContext:
* Currently there are three valid bits in SecurityRestrictionContext:
*
* SECURITY_LOCAL_USERID_CHANGE indicates that we are inside an operation
* that is temporarily changing CurrentUserId via these functions. This is
@ -359,6 +359,13 @@ GetAuthenticatedUserId(void)
* where the called functions are really supposed to be side-effect-free
* anyway, such as VACUUM/ANALYZE/REINDEX.
*
* SECURITY_NOFORCE_RLS indicates that we are inside an operation which should
* ignore the FORCE ROW LEVEL SECURITY per-table indication. This is used to
* ensure that FORCE RLS does not mistakenly break referential integrity
* checks. Note that this is intentionally only checked when running as the
* owner of the table (which should always be the case for referential
* integrity checks).
*
* Unlike GetUserId, GetUserIdAndSecContext does *not* Assert that the current
* value of CurrentUserId is valid; nor does SetUserIdAndSecContext require
* the new value to be valid. In fact, these routines had better not
@ -401,6 +408,15 @@ InSecurityRestrictedOperation(void)
return (SecurityRestrictionContext & SECURITY_RESTRICTED_OPERATION) != 0;
}
/*
* InNoForceRLSOperation - are we ignoring FORCE ROW LEVEL SECURITY ?
*/
bool
InNoForceRLSOperation(void)
{
return (SecurityRestrictionContext & SECURITY_NOFORCE_RLS) != 0;
}
/*
* These are obsolete versions of Get/SetUserIdAndSecContext that are