Tom Lane <t...@sss.pgh.pa.us> wrote:
> Well, the approach you suggested of putting a security wrapper
> around the output column might be bulletproof against that; I'm
> not entirely sure, but I don't see a hole in it at the moment.
> The trouble with it is that it's pretty bad from a performance
> point of view, at least for columns that people are supposed to be
> able to use in WHERE clauses.
OK. We don't really intend for such columns to be used for
selection criteria or sorting, so I think we're fine. :-) Thanks
for the clarification.
> The angst here is about row filtering.
OK, I think we're all back on the same page. I only posted because
Robert questioned whether there was any security use case for
current views.
> The stronger form is that they shouldn't even be able to tell that
> hidden rows exist, which is something your view doesn't try to do;
> but there are at least some applications where that would be
> desirable.
I can understand that, but from what I've read on the topic, it
seems that even some of the most security-conscious government and
military users concede that point and just go with meaningless
identifiers for inter-table references, so that what leaks is
meaningless.
<digression>
The courts have needs which are a bit different than some other
security users; it generally comes down to balancing privacy rights
against the rights of the public to access matters of public record.
Through the continuing efforts of various committees
recommendations, supreme court rules, and legislation, we have one
view of the data which is available on the Internet, a more generous
view of a county's data if you actually walk into that county's
courthouse and use a public access workstation, another level for
all parties on certain case types (with the ability to secure some
of the data about one party from others if ordered by the court),
and then it gets really complicated when you get to what different
court staff are allowed to see or modify. Then there can be special
exceptions for some business partners, like children's services or
police agencies.
Right now this is managed by query classes in our Java applications,
but as we're moving to a variety of new and different technologies
it's getting harder for the DBAs to ensure that nothing is leaking
to inappropriate recipients. :-( I think we're going to need to
move more of the enforcement to database views and/or security
restrictions based on database roles.
Some of this seems to fit fairly neatly with the general direction
in which KaiGai has been pushing; some of it maybe not so much,
because we don't operate on something as simple as "secret", "top
secret", etc. But we could use some of the features which seem to
be considered pretty esoteric -- like showing different versions of
a row to people with different security. For example, on a court
calendar, as available to the public in the courthouse for cases
scheduled on the current date, a juvenile case would show the
child's initials ("In the Interest of J.D."), while the case would
not show for the public on the Internet, but the judge involved and
the deputy clerks of court who deal with juvenile cases would see
the entire name.
</digression>
Sorry for drifting off topic....
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
