rolbypassrls bool
- Role bypasses every row level security policy, see
+ Role bypasses every row-level security policy, see
for more information.
relrowsecurity bool
- True if table has row level security enabled; see
+ True if table has row-level security enabled; see
pg_policy catalog
relforcerowsecurity bool
- True if row level security (when enabled) will also apply to table owner; see
+ True if row-level security (when enabled) will also apply to table owner; see
pg_policy catalog
- The catalog pg_policy stores row level
+ The catalog pg_policy stores row-level
security policies for tables. A policy includes the kind of
command that it applies to (possibly all commands), the roles that it
applies to, the expression to be added as a security-barrier
rolbypassrls bool
- Role bypasses every row level security policy, see
+ Role bypasses every row-level security policy, see
for more information.
usebypassrls bool
- User bypasses every row level security policy, see
+ User bypasses every row-level security policy, see
for more information.
usebypassrls bool
- User bypasses every row level security policy, see
+ User bypasses every row-level security policy, see
for more information.
INSERT INTO passwd VALUES
('alice','xxx',2,1,'Alice','098-765-4321',null,'/home/alice','/bin/zsh');
--- Be sure to enable row level security on the table
+-- Be sure to enable row-level security on the table
ALTER TABLE passwd ENABLE ROW LEVEL SECURITY;
-- Create policies
ALTER POLICY
- change the definition of a row level security policy
+ change the definition of a row-level security policy
These forms control the application of row security policies belonging
to the table. If enabled and no policies exist for the table, then a
default-deny policy is applied. Note that policies can exist for a table
- even if row level security is disabled. In this case, the policies will
+ even if row-level security is disabled. In this case, the policies will
not be applied and the policies will be ignored.
See also
CREATE POLICY.
These forms control the application of row security policies belonging
- to the table when the user is the table owner. If enabled, row level
+ to the table when the user is the table owner. If enabled, row-level
security policies will be applied when the user is the table owner. If
- disabled (the default) then row level security will not be applied when
+ disabled (the default) then row-level security will not be applied when
the user is the table owner.
See also
CREATE POLICY.
CREATE POLICY
- define a new row level security policy for a table
+ define a new row-level security policy for a table
Any
SQL conditional expression (returning
boolean). The conditional expression cannot contain
any aggregate or window functions. This expression will be added
- to queries that refer to the table if row level security is enabled.
+ to queries that refer to the table if row-level security is enabled.
Rows for which the expression returns true will be visible. Any
rows for which the expression returns false or null will not be
visible to the user (in a SELECT), and will not be
boolean). The conditional expression cannot contain
any aggregate or window functions. This expression will be used in
INSERT and UPDATE queries against
- the table if row level security is enabled. Only rows for which the
+ the table if row-level security is enabled. Only rows for which the
expression evaluates to true will be allowed. An error will be thrown
if the expression evaluates to false or null for any of the records
inserted or any of the records that result from the update. Note that
DROP POLICY
- remove a row level security policy from a table
+ remove a row-level security policy from a table
DROP POLICY removes the specified policy from the table.
Note that if the last policy is removed for a table and the table still has
- row level security enabled via ALTER TABLE, then the
+ row-level security enabled via ALTER TABLE, then the
default-deny policy will be used. ALTER TABLE ... DISABLE ROW
- LEVEL SECURITY can be used to disable row level security for a
+ LEVEL SECURITY can be used to disable row-level security for a
table, whether policies for the table exist or not.
- When it is necessary for a view to provide row level security, the
+ When it is necessary for a view to provide row-level security, the
security_barrier attribute should be applied to
the view. This prevents maliciously-chosen functions and operators from
being passed values from rows until after the view has done its work. For
CURSOR_OPT_PARALLEL_OK, NULL);
/*
- * With row level security and a user using "COPY relation TO", we
+ * With row-level security and a user using "COPY relation TO", we
* have to convert the "COPY relation TO" to a query-based COPY (eg:
* "COPY (SELECT * FROM relation) TO"), to allow the rewriter to add
* in any RLS clauses.
/*
* Only superuser is allowed to create leakproof functions because
* leakproof functions can see tuples which have not yet been filtered out
- * by security barrier views or row level security policies.
+ * by security barrier views or row-level security policies.
*/
if (isLeakProof && !superuser())
ereport(ERROR,
* Returns true if permissions are adequate. Otherwise, throws an appropriate
* error if ereport_on_violation is true, or simply returns false otherwise.
*
- * Note that this does NOT address row level security policies (aka: RLS). If
+ * Note that this does NOT address row-level security policies (aka: RLS). If
* rows will be returned to the user as a result of this permission check
* passing, then RLS also needs to be consulted (and check_enable_rls()).
*
*
* Note that this needs to be called multiple times to ensure that all kinds of
* WITH CHECK OPTIONs are handled (both those from views which have the WITH
- * CHECK OPTION set and from row level security policies). See ExecInsert()
+ * CHECK OPTION set and from row-level security policies). See ExecInsert()
* and ExecUpdate().
*/
void
/*
* If the subquery has the "security_barrier" flag, it means the subquery
- * originated from a view that must enforce row level security. Then we
+ * originated from a view that must enforce row-level security. Then we
* must not push down quals that contain leaky functions. (Ideally this
* would be checked inside subquery_is_pushdown_safe, but since we don't
* currently pass the RTE to that function, we must do it here.)
QTW_IGNORE_RC_SUBQUERIES);
/*
- * Apply any row level security policies. We do this last because it
+ * Apply any row-level security policies. We do this last because it
* requires special recursion detection if the new quals have sublink
* subqueries, and if we did it in the loop above query_tree_walker would
* then recurse into those quals a second time.
}
/*
- * Make sure the query is marked correctly if row level security
+ * Make sure the query is marked correctly if row-level security
* applies, or if the new quals had sublinks.
*/
if (hasRowSecurity)
/*
* rewrite/rowsecurity.c
- * Routines to support policies for row level security (aka RLS).
+ * Routines to support policies for row-level security (aka RLS).
*
* Policies in PostgreSQL provide a mechanism to limit what records are
* returned to a user and what records a user is permitted to add to a table.
* Get any row security quals and WithCheckOption checks that should be
* applied to the specified RTE.
*
- * In addition, hasRowSecurity is set to true if row level security is enabled
+ * In addition, hasRowSecurity is set to true if row-level security is enabled
* (even if this RTE doesn't have any row security quals), and hasSubLinks is
* set to true if any of the quals returned contain sublinks.
*/
bool rolcreatedb; /* allowed to create databases? */
bool rolcanlogin; /* allowed to log in as session user? */
bool rolreplication; /* role used for streaming replication */
- bool rolbypassrls; /* bypasses row level security? */
+ bool rolbypassrls; /* bypasses row-level security? */
int32 rolconnlimit; /* max connections allowed (-1=no limit) */
/* remaining fields may be null; use heap_getattr to read them! */
ALTER TABLE t ENABLE ROW LEVEL SECURITY;
SAVEPOINT q;
CREATE RULE "_RETURN" AS ON SELECT TO t DO INSTEAD
- SELECT * FROM generate_series(1,5) t0(c); -- fails due to row level security enabled
+ SELECT * FROM generate_series(1,5) t0(c); -- fails due to row-level security enabled
ERROR: could not convert table "t" to a view because it has row security enabled
ROLLBACK TO q;
ALTER TABLE t DISABLE ROW LEVEL SECURITY;
SAVEPOINT q;
CREATE RULE "_RETURN" AS ON SELECT TO t DO INSTEAD
- SELECT * FROM generate_series(1,5) t0(c); -- fails due to row level security enabled
+ SELECT * FROM generate_series(1,5) t0(c); -- fails due to row-level security enabled
ROLLBACK TO q;
ALTER TABLE t DISABLE ROW LEVEL SECURITY;