1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-02 09:02:37 +03:00

Remove the SECURITY_ROW_LEVEL_DISABLED security context bit.

This commit's parent made superfluous the bit's sole usage.  Referential
integrity checks have long run as the subject table's owner, and that
now implies RLS bypass.  Safe use of the bit was tricky, requiring
strict control over the SQL expressions evaluating therein.  Back-patch
to 9.5, where the bit was introduced.

Based on a patch by Stephen Frost.
This commit is contained in:
Noah Misch
2015-09-20 20:47:17 -04:00
parent 6dae6edcd8
commit bbdb9dfbc3
6 changed files with 4 additions and 49 deletions

View File

@ -2970,7 +2970,6 @@ ri_PlanCheck(const char *querystr, int nargs, Oid *argtypes,
Relation query_rel;
Oid save_userid;
int save_sec_context;
int temp_sec_context;
/*
* Use the query type code to determine whether the query is run against
@ -2983,22 +2982,8 @@ ri_PlanCheck(const char *querystr, int nargs, Oid *argtypes,
/* Switch to proper UID to perform check as */
GetUserIdAndSecContext(&save_userid, &save_sec_context);
/*
* Row-level security should be disabled in the case where a foreign-key
* relation is queried to check existence of tuples that references the
* primary-key being modified.
*/
temp_sec_context = save_sec_context | SECURITY_LOCAL_USERID_CHANGE;
if (qkey->constr_queryno == RI_PLAN_CHECK_LOOKUPPK
|| qkey->constr_queryno == RI_PLAN_CHECK_LOOKUPPK_FROM_PK
|| qkey->constr_queryno == RI_PLAN_RESTRICT_DEL_CHECKREF
|| qkey->constr_queryno == RI_PLAN_RESTRICT_UPD_CHECKREF)
temp_sec_context |= SECURITY_ROW_LEVEL_DISABLED;
SetUserIdAndSecContext(RelationGetForm(query_rel)->relowner,
temp_sec_context);
save_sec_context | SECURITY_LOCAL_USERID_CHANGE);
/* Create the plan */
qplan = SPI_prepare(querystr, nargs, argtypes);

View File

@ -204,7 +204,6 @@ CreateCachedPlan(Node *raw_parse_tree,
plansource->total_custom_cost = 0;
plansource->num_custom_plans = 0;
plansource->hasRowSecurity = false;
plansource->rowSecurityDisabled = InRowLevelSecurityDisabled();
plansource->row_security_env = row_security;
plansource->planUserId = InvalidOid;
@ -601,17 +600,10 @@ RevalidateCachedQuery(CachedPlanSource *plansource)
}
/*
* Check if row security is enabled for this query and things have changed
* such that we need to invalidate this plan and rebuild it. Note that if
* row security was explicitly disabled (eg: this is a FK check plan) then
* we don't invalidate due to RLS.
*
* Otherwise, if the plan has a possible RLS dependency, force a replan if
* either the role under which the plan was planned or the row_security
* setting has been changed.
* If the plan has a possible RLS dependency, force a replan if either the
* role or the row_security setting has changed.
*/
if (plansource->is_valid
&& !plansource->rowSecurityDisabled
&& plansource->hasRowSecurity
&& (plansource->planUserId != GetUserId()
|| plansource->row_security_env != row_security))

View File

@ -341,7 +341,7 @@ GetAuthenticatedUserId(void)
* GetUserIdAndSecContext/SetUserIdAndSecContext - get/set the current user ID
* and the SecurityRestrictionContext flags.
*
* Currently there are three valid bits in SecurityRestrictionContext:
* Currently there are two 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,9 +359,6 @@ GetAuthenticatedUserId(void)
* where the called functions are really supposed to be side-effect-free
* anyway, such as VACUUM/ANALYZE/REINDEX.
*
* SECURITY_ROW_LEVEL_DISABLED indicates that we are inside an operation that
* needs to bypass row level security checks, for example FK 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
@ -404,15 +401,6 @@ InSecurityRestrictedOperation(void)
return (SecurityRestrictionContext & SECURITY_RESTRICTED_OPERATION) != 0;
}
/*
* InRowLevelSecurityDisabled - are we inside a RLS-disabled operation?
*/
bool
InRowLevelSecurityDisabled(void)
{
return (SecurityRestrictionContext & SECURITY_ROW_LEVEL_DISABLED) != 0;
}
/*
* These are obsolete versions of Get/SetUserIdAndSecContext that are

View File

@ -63,13 +63,6 @@ check_enable_rls(Oid relid, Oid checkAsUser, bool noError)
if (relid < FirstNormalObjectId)
return RLS_NONE;
/*
* Check if we have been told to explicitly skip RLS (perhaps because this
* is a foreign key check)
*/
if (InRowLevelSecurityDisabled())
return RLS_NONE;
tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid));
if (!HeapTupleIsValid(tuple))
return RLS_NONE;