Re: [PATCH] Fix leaky VIEWs for RLS
От | KaiGai Kohei |
---|---|
Тема | Re: [PATCH] Fix leaky VIEWs for RLS |
Дата | |
Msg-id | 4C0CA016.5070204@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Fix leaky VIEWs for RLS (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: [PATCH] Fix leaky VIEWs for RLS
|
Список | pgsql-hackers |
(2010/06/07 15:48), Heikki Linnakangas wrote: > On 07/06/10 06:06, Stephen Frost wrote: >> Also, perhaps I'm not being paranoid enough, but all this concern over >> error cases really doesn't really worry me that much. The amount of >> data one could acquire that way is pretty limited. > > It's not limited. It allows you to read all contents of the underlying > table or tables. I don't see much point doing anything at all if we > don't plug that. > IIRC, Oracle pays attention not to expose function's arguments via error messages due to the security reasons, although it focuses on that does not provide a hint to attacker who tries SQL injection. It seems to me it is a matter of degree. If we allows to execute lowrite() inside of the join loop, it can be abused to move massive invisible information into visible large objects within a little time. So, its priority is relatively higher than error messages. However, we cannot move massive information via error messages in a little time, although it may expose whole of the arguments. So, its threat is relatively smaller. > There's many side channels like exposing row counts in EXPLAIN and > statistics and timing attacks, that are not as critical, because they > don't let expose all data, and the attacker can't accurately choose what > data is exposed. Those are not as important. > It also means; because they can provide much smaller bandwidth to leak invisible information than error messages, these are not as important. Is it right? Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: