Joshua Brindle <method@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.)
Now that you've admitted that you aren't trying to accomplish the
equivalent sort of data hiding within the filesystem, the argument that
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
accomplish similar goals with just table- and column-level access
permissions, which are well understood and don't violate anyone's
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.
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.
regards, tom lane
