On Mon, Feb 16, 2009 at 9:53 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> Gregory Stark <st...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers