Re: [v9.4] row level security

Поиск
Список
Период
Сортировка
От Kohei KaiGai
Тема Re: [v9.4] row level security
Дата
Msg-id CADyhKSWkHrPqbRsFK0LjPMOOTsbKGWOuN75GqYJrxCDO3CKWtA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [v9.4] row level security  (Oleg Bartunov <obartunov@gmail.com>)
Ответы Re: [v9.4] row level security
Re: [v9.4] row level security
Список pgsql-hackers
2013/8/28 Oleg Bartunov <obartunov@gmail.com>:
> btw, there is serious problem with row-level security and constraints. For
> example, user with low security level could use unique constraint to know
> about existence of a row with higher security.  I don't know, what is the
> best practice to avoid this.
>
It is out of scope for this feature. We usually calls this type of information
leakage "covert channel"; that is not avoidable in principle.
However, its significance is minor, because attacker must know identical
data to be here, or must have proving for each possible values.
Its solution is simple. DBA should not use value to be confidential as unique
key. If needed, our recommendation is alternative key, instead of natural key,
because its value itself does not have worth.

I should add a note of caution onto the documentation according to
the previous consensus, however, I noticed it had gone from the sgml files
while I was unaware. So, let me add description on the documentation.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.4] row level security
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY