Re: [PATCH] Fix leaky VIEWs for RLS
От | Heikki Linnakangas |
---|---|
Тема | Re: [PATCH] Fix leaky VIEWs for RLS |
Дата | |
Msg-id | 4C0CDDCB.5050602@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Fix leaky VIEWs for RLS (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [PATCH] Fix leaky VIEWs for RLS
Re: [PATCH] Fix leaky VIEWs for RLS |
Список | pgsql-hackers |
On 07/06/10 14:06, Stephen Frost wrote: > * Heikki Linnakangas (heikki.linnakangas@enterprisedb.com) wrote: >> The big difference is what information can be obtained, not how fast it >> can be obtained. > > Actually, I disagree. Time required to acquire the data does matter. Depends on the magnitude, of course. If it takes 1 year per row, that's probably acceptable. If it takes 1 second, that's extremely slow compared to normal queries, but most likely still disastreous from a security point of view. >> Imagine a table that holds username/passwords for users. Each user is >> allowed to see his own row, including password, but not anyone else's. >> EXPLAIN side-channel might give pretty accurate information of how many >> rows there is in the table, and via clever EXPLAIN+statistics probing >> you might be able to find out what the top-10 passwords are, for >> example. But if you wanted to know what your neighbor's password is, the >> side-channels would not help you much, but an error message would reveal >> it easily. > > Using only built-ins, could you elaborate on how one could pick exactly > what row was revealed using an error case? That strikes me as > difficult, but perhaps I'm not thinking creatively enough. WHERE should do it: SELECT * FROM secrets_view WHERE username = 'neighbor' AND password::integer = 1234; ERROR: invalid input syntax for integer: "neighborssecretpassword" Assuming that username = 'neighbor' is evaluated before the cast. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: