Ron Mayer wrote:
Stephen Frost wrote:
And, just to go full circle, row-level access controls are exactly what
the other enterprise RDBMSs have and is what is used in these security
circles today. One of the major issues, as I understand it, is to be
able to use stock applications with multiple security levels where the
application doesn't know (or care about) the security level. Doing that
through views and partitions and triggers and whatnot for each and every
application that is run on these systems will be a big hurdle to those
users, if it ends up being workable at all.
That seems to me to be a shortcoming of the partition system and a good
TODO for the future partitioning improvements.
Why shouldn't be just as easy to make sure a row ends up in the
right partition as opposed to making sure it's tagged with right
row-level ACLs.
In reality it isn't, unless postgres won't mind thousands of partitions being
made. In the military/gov implementations BLP lets you have hierarchical levels
and non-hierarchical categories. Since I linked to an article about it upthread
I assumed everyone participating was familiar but perhaps not. Typically there
are 3 levels, unclass, secret, top secret. In addition to those 3 levels there
may be a few, hundreds or even thousands of categories. Those categories apply
to each of the levels so if you are using 1000 categories you have 3*1000
possible BLP labels. On top of that SELinux has users, roles and types, which
are all also multiplied.
There is a reason we don't do things like have 3 filesystems, one for unclass,
one for secret and one for top secret.
Partitions/views may be a good way to implement row-level access control when
there are a few different options but they won't necessarily be known ahead of
time. We don't want to encode policy logic in to the database itself, that is
why we have a separate security server that handles the policy. The system
should scale to any number of contexts that are available on the system.
Relabeling with partitions (that is, moving things from one partition to
another) seems to be handled with triggers, which is inconvenient to the
application developers but also devastating to the security system (unless you
can map triggers back to who did the operation that caused them), and managing
partitions on dozens or hundreds of tables and moving data between them in those
tables seems at the very least challenging.
I also have questions concerning partitions. Perhaps someone wants to use
partitions for a functional purpose (eg., to split log entries by month/year).
What would be the affect of concurrently using partitions to split security
contexts out?
Nonetheless, this conversation seems moot now that Tom has walled off and won't
even discuss row-level access controls.
Cheers.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
