Re: SE-PostgreSQL and row level security
От | Robert Haas |
---|---|
Тема | Re: SE-PostgreSQL and row level security |
Дата | |
Msg-id | 603c8f070902160702l29ca3aa2jf6e76d5eeb8624e8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SE-PostgreSQL and row level security (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: