On Mon, Feb 16, 2009 at 9:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Gregory Stark <stark@enterprisedb.com> wrote:
>>> And it doesn't accomplish anything since the covert
>>> channels it attempts to address are still open.
>
>> Hyperbole. We're not very likely to go the SE-* route, but I can say
>> that we've got some of the issues it addresses, and it is a very
>> different thing for someone to know, for example, that there is a
>> paternity case 2009PA000023 in a county, and for them to know what the
>> case caption is (which includes the names).
>
> Which is something you could implement with standard SQL column
> permissions; and could *not* implement with row-level access
> permissions. Row-level is all or nothing for each row.
Huh?
The scenario I think we're talking about here is a user who has
permissions to SELECT and INSERT and UPDATE a subset of the records in
a table. Because there is a unique index on the case name, if he
happens to try to insert a new case called 2009PA000023, it will fail,
and he will gain some information about a row he can't see. But since
that information is a sequentially assigned key, it's not very useful
- it doesn't reveal any of the other attributes of the unseen row,
which is where the really sensitive data is.
Column-level privileges would not let you implement this at all.
...Robert