Row policies are enabled on a table, yet the application still reads every tenant's rows in production. What ownership or privilege explanations would you check, and how do you close each one?

## Why "enabled" is not the same as "enforced" Row-level security has a surprising number of legitimate exemptions, and every one of them is a way to ship a table that looks protected in the schema and is wide open at runtime. This is one of the most common real interview scenarios because it is one of the most common production incidents. ## 1. The table owner By default the owner of a table is exempt from its own policies. The reasoning is ownership: the owner defines the policies and must be able to inspect, back up and repair the data. The consequence is brutal in the common deployment where the application connects with the same role that ran the migrations and therefore owns every table — policies exist, tests written as that role pass, and nothing is filtered. Two fixes, both worth doing: (a) split roles, so migrations run as an owner/DDL role and the application runs as a separate role with only DML privileges; (b) *force* row-level security on the table, an explicit flag that makes even the owner subject to its policies. Forcing is also what makes it safe to write policies you intend as absolute. ## 2. Superuser and bypass attributes Superusers skip all policies. So does any role carrying an explicit bypass-RLS attribute, which exists precisely so backup and replication tooling can read everything. Both are inheritable through role membership, so a role that looks ordinary can be exempt because it is a member of an admin group. Check the *effective* attributes of the connecting role, not just the row in the role catalog for its own name. Give backup/ETL identities the bypass attribute deliberately and nothing else. ## 3. A permissive policy you forgot Policies default to **permissive** and combine with OR. Adding a policy therefore never narrows access; it widens it. A very common failure: someone adds `CREATE POLICY tmp_debug ... USING (true)` to unblock an investigation, or a broad "admin can see everything" policy is defined `TO PUBLIC` instead of `TO admin_role`. From then on, the strict tenant policy is irrelevant because every row satisfies the other branch. The defence is to enumerate every policy on the table during review — not just the one you wrote — and to express mandatory conditions as **restrictive** policies, which AND in and therefore cannot be widened away by a future permissive addition. ## 4. Views and functions with definer's rights A view traditionally executes against its base tables with the privileges and identity of the *view owner*, not the caller. If a reporting view sits over a protected table and the view is owned by a privileged role, callers of the view get unfiltered rows. Modern engines offer an invoker-rights option for views; turn it on for anything sitting above an RLS-protected table, or make the view owner a role that is itself subject to the policies. The same applies to security-definer stored functions: inside them, the effective identity is the definer. That is sometimes exactly what you want (a validated context setter), but a generic "fetch report" definer function silently punches through your policies. ## 5. Related near-misses - **RLS never enabled on this table.** Policies can be defined while the table-level switch is off; they simply do nothing. Check the table's RLS flag, not just the existence of policies. - **Only some commands covered.** A policy `FOR SELECT` leaves UPDATE and DELETE governed by nothing — and with RLS enabled, the fail-closed default actually blocks them, which shows up as broken writes rather than leaks. The mirror image is a `FOR ALL` policy with an over-broad predicate. - **Partitions and inheritance.** Whether policies on a parent apply to partitions, and whether a partition carries its own, is an engine-specific detail worth verifying by test. ## How to verify rather than assume The only trustworthy check is behavioural: connect as the exact production application role, set a tenant context, and count rows for a foreign tenant. Assert zero. Do that in CI, on every deploy, with a role created the same way production's is. Reading the schema and concluding "policies exist, we are fine" is how every one of the causes above survives review.