Aller au contenu
Source

PostgreSQL — Row Security Policies (RLS)

RLS est une barrière moteur solide mais pas magique : rôle applicatif non superuser, fonctions non leakproof à surveiller, sauvegardes avec `row_security = off`.

Confirmée#pgvector#permissions#securitePublié le 16 sept. 2026Mis à jour le 16 sept. 2026Vérifié le 16 sept. 2026À revérifier le 15 déc. 2026
URL
https://www.postgresql.org/docs/current/ddl-rowsecurity.html
Organisation
PostgreSQL
Type
Documentation officielle
Fiabilité
Fiabilité haute
Publié
documentation courante
Consulté le
16 septembre 2026
Sujets
pgvector, permissions, securite

Citée par 4 page(s)

Base vectorielle : pgvector, Qdrant et alternativesRAG · Comparaison des bases vectorielles auto-hébergeables pour la Box (filtrage ACL imposé par le moteur, hybride, multi-tenant, licence, exploitation) et recommandation provisoire liée à Q-004.Permissions et confidentialité dans le RAGRAG · Comment garantir qu'un utilisateur ne récupère jamais un passage d'un dossier auquel il n'a pas accès : ACL par chunk, filtre côté serveur, double barrière application + moteur, audit et tests.pgvector vs Qdrant : rappel et latence de la recherche filtrée par ACLExpérimentation · Mesurer la perte de rappel et la latence d'une recherche vectorielle filtrée par dossier_id (10 %, 30 %, 100 % de portée) avec pgvector HNSW (sans et avec iterative_scan, RLS) et Qdrant (payload is_tenant, JWT payload).Test de fuite de permissions du RAG (« l'avocat B ne voit jamais A »)Expérimentation · Corpus fictif à canaris, batterie de questions par utilisateur, vérification des chunks récupérés, des réponses et du journal, avec et sans barrière applicative.

Ce que dit la source : ENABLE ROW LEVEL SECURITY, FORCE ROW LEVEL SECURITY, CREATE POLICY … USING … WITH CHECK. Les superusers et rôles BYPASSRLS contournent toujours RLS. Avertissements : « The only exceptions to this rule are leakproof functions … the optimizer may choose to apply such functions ahead of the row-security check » ; « such accesses can create race conditions that could allow information leakage if care is not taken » ; « Referential integrity checks … always bypass row security … Care must be taken … to avoid "covert channel" leaks » ; pour les sauvegardes, row_security = off afin de forcer une erreur plutôt qu'une omission silencieuse.

Ce qu'on en retient : RLS est une barrière moteur solide mais pas magique : rôle applicatif non superuser, fonctions non leakproof à surveiller, sauvegardes avec row_security = off.

Limites : l'interaction avec l'opérateur de distance pgvector (leakproof ou non) n'est pas documentée ici (estimation).

content/sources/postgresql-row-security.md158 mots