liveBook · Manning

Row-level security

As explained in PostgreSQL Mistakes and How to Avoid Them

Row-level security is a database access-control mechanism that restricts which table rows individual users can access.

Row-level security (RLS) restricts table rows for individual users, but PostgreSQL superusers can bypass those policies indirectly through objects they own. section 8.4

The superuser-owned view leak

An unprivileged account subject to RLS selects from a view and unexpectedly receives rows. Because the view is owned by a superuser, PostgreSQL bypasses most permission checks, so the RLS policy is not applied through that view. Avoid unnecessary superuser ownership and investigate security_barrier views as a separate protection against view data leaks. section 8.4

CREATE DATABASE frogge_next OWNER postgres;

Use the database-ownership listing to recognize how assigning ownership to postgres can attach excessive privilege to database objects. section 8.4

How PostgreSQL Mistakes and How to Avoid Them covers it

How deep it goes
Explains RLS bypass through superuser-owned views and points to security_barrier protection without detailing policy syntax.
Examples
Uses an unprivileged user querying a superuser-owned view and receiving rows despite RLS restrictions.
What it assumes
Assumes familiarity with PostgreSQL users, roles, views, superusers, and permission checks.
What you can do after
Diagnose unexpected row exposure by checking view ownership and considering security_barrier protection.
How it connects
Connects RLS with views, superusers, roles, privilege checks, and security_barrier.

Also explained in

Compare how 2 books explain row-level security →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of PostgreSQL Mistakes and How to Avoid Them. The section links point to the parts of the book it draws on.