Sorry for top-posting and avoiding to paste online doc URL.
Joshua, you sound like you're missing an important point. Sorry for
misunderstanding if that's not true.
Partitioning is supported in a way that a query does not need to know
about it, be it a SELECT, INSERT, UPDATE or DELETE. And 8.4 onwards,
some more.
What Tom is talking about is adding support for discarding partitions
based on GRANTed rights rather than WHERE clauses.
No application rewrite.
Columns obfuscating remains to be cared of: what about allowing views
as partitions?
HTH, regards,
--
dim
Le 28 janv. 09 à 19:49, Joshua Brindle <met...@manicmethod.com> a
écrit :
Tom Lane wrote:
Joshua Brindle <met...@manicmethod.com> writes:
I'm not sure how much it would cut to remove row level access
controls, but I do have some points here. To me, row level access
controls are the most important part, this is the feature that
lets us
put secret and top secret data in the same table and use the clients
selinux context to decide what they can see,
For me, the row-level access controls are really the sticking point.
There is absolutely nothing you can say that will convince me that
they
don't break SQL in fundamental ways, and I also don't believe that
it's
going to be possible to implement them without a constant stream of
bugs
of omission and commission. (Those two points are not unrelated.)
This isn't going to be something that the vast majority of your
users use. The people that need them understand the ramifications of
row filtering and the absence of inaccessible rows won't be
surprising.
Now that you've admitted that you aren't trying to accomplish the
equivalent sort of data hiding within the filesystem, the argument
that
We apply access controls on reading and writing files, this is
equivalent (in my mind) to applying access controls on tuples, as
they are the structured object holding data (just like files).
you have to have them seems fairly weak, certainly not strong
enough to
justify the costs. We have already touched on some ways that you can
The costs are nil for people who don't want this feature.
accomplish similar goals with just table- and column-level access
permissions, which are well understood and don't violate anyone's
I've already pointed out how table and column level access control
don't provide enough. Holding data of multiple classifications in a
single table is something of great concern. Unmodified applications
need to be able to query out of a table and get the data they are
cleared to see. Column level access control doesn't help because
those same applications, of course, will need access to the data in
those columns.
Splitting data into different tables isn't an option in many cases
because applications aren't always configurable wrt to the database
or tables they use. Further, clients of multiple clearances should
be able to use the same application, and we can not trust the
application to make the decision as to which database or table is
correct.
And even further, maintaining multiple sets of databases or tables
that hold the same kinds of information (and therefore have the same
schema) is a maintenance, backup and restoration issue.
expectations. There's probably a need to twiddle our permissions
rules
for inheritance/partitioning cases, but that was already on the table
anyway for other reasons.
partitions don't help because, once again, the application would be
making the determination about which partition to query. For
mandatory access control that we need in the kind of environments to
work the application doesn't get to make security relevant
decisions, the database holds the data and needs to say who can
access it.
Further, partitioning isn't fine grained. I can't say user X can
read secret rows and read/write top secret rows and get that data
out in a transparent way (the applications would have to be aware of
the partitions). Relabeling of data also looks like a challenge with
partitions (if I correctly understand how they work).
I could be persuaded to get behind a patch that does Peter's step #1
(ie, use SELinux permissions as an additional filter for existing SQL
permission checks). I don't believe I will ever think that row-level
checks are a good idea; as long as those are in the patch I will vote
against applying it.
We've already used postgresql in sensitive environments and had to
make compromises because of the lack of fine grained access control.
We've been telling customers for years that we hope postgresql will
have said access controls in the future and that it will help them
solve many of the problems they have.
We've been enthusiastic about the work KaiGai has been doing with
respect to the environments we operate in and it would be a shame
for all that to be discarded.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
