Re: RLS Design - Mailing list pgsql-hackers

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
ALLOWrules, 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,
likewe 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
GRANTedaccess 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
rulesare ANDed with any row security predicates in the catalogs, but we'd want the option of treating them as ALLOW or
DENYrules 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
inthe 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
allowedto 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
createdbefore 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