Re: RLS Design

Hi all

I was jotting notes about this last sleepless night, and was really glad
to see the suggestion of enabling RLS on a table being a requirement for
OR-style quals suggested in the thread when I woke.

The only sane way to do OR-ing of multiple rules is to require that
tables be switched to deny-by-default before RLS quals can be added to
then selectively enable access.

The next step is DENY rules that override ALLOW rules, and are also
ORed, so any DENY rule overrides any ALLOW rule. Like in ACLs. But that
can be a "later" - I just think room for it should be left in any
catalog definition.

My concern with the talk of policies, etc, is with making it possible to
impliment this for 9.5. I'd really like to see a robust declarative
row-security framework with access policies - but I'm not sure sure it's
a good idea to try to assemble policies directly out of low level row
security predicates.

Tying things into a policy model that isn't tried or tested might create
more problems than it solves unless we implement multiple real-world
test cases on top of the model to show it works.

For how I think we should be pursuing this in the long run, take a look
at how TeraData does it, with heirachical and non-heirachical rules -
basically bitmaps or thresholds - that get grouped into access policies.
It's a very good way to abstract the low level stuff. If we have low
level table predicate filters, we can build this sort of thing on top.

For 9.5, unless the basics turn out to be way easier than they look and
it's all done soon in the release process, surely we should be sticking
to just getting the basics of row security in place? Leaving room for
enhancement, sure, but sticking to the core feature which to my mind is:

- A row security on/off flag for a table;

- Room in the catalogs for multiple row security rules per table
and a type flag for them. The initial type flag, for ALLOW rules,
specifies that all ALLOW rules be ORed together.

- Syntax for creating and dropping row security predicates. If there
can be multiple ones per table they'll need names, like we have with
triggers, indexes, etc.

- psql support for listing row security predicates on a table if running
as superuser or if you've been explicitly GRANTed access to the
catalog table listing row security quals.

- The hooks for contribs to inject their own row security rules. The
API will need a tweak - right now it assumes these rules are ANDed
with any row security predicates in the catalogs, but we'd want the
option of treating them as ALLOW or DENY rules to get ORed with the
rest of the set *or* as a pre-filter predicate like currently.

- A row-security-exempt right, at the user-level,
to assuage the concerns about malicious predicates. I maintain that
in the first rev this should be simple: "superuser is row security
exempt". I don't think I'm going to win that one though, so a
user/role attribute that makes the role ignore row security
seems like the next simplest option.

- A way to test whether the current user is row-security exempt
so pg_dump can complain unless explicitly told it's allowed
to do a selective dump via a cmdline option;

Plus a number of fixes:

- Fixing the security barrier view isssue with row level lock pushdown
that's breaking the row security regression tests;

- Enhancing plan cache invalidation so that row-security exempt-ness
of a user is part of the plancache key;

- Adding session state like current_user to portals, so security_barrier
functions returning refcursor, and cursors created before SET SESSION
AUTHORIZATION or SET ROLE, get the correct values when they use
session information like current_user

Note that this doesn't even consider the "with check option" style
write-filtering side of row security and the corresponding challenges
with the semantics around RETURNING.

It's already a decent sized amount of work on top of the existing row
security patch.

If we start adding policy groups, etc, this will never get done.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services