Re: Review of Row Level Security

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Review of Row Level Security
Дата
Msg-id 20121219194619.14740@gmx.com
обсуждение исходный текст
Ответ на Review of Row Level Security  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Review of Row Level Security
Re: Review of Row Level Security
Re: Review of Row Level Security
Список pgsql-hackers
Simon Riggs wrote:

> This is security, not spec compliance. By default, we need full
> security.

But you are arguing that users should not be able to make something
secure if they, and everyone with the same permissions, could not
later access it. I thought about situations where I've seen a need
for something like this, and probably the best fit that I've seen
is the ability of a judge to order that something is sealed. There
are various levels where that can happen, but I'll focus on just
one which Wisconsin Courts have implemented at the application
level, but which would be nice to be able to support at the
database level.

Let's say we're talking about Milwaukee County, where hundreds of
people work for the courts and related organizations with some
rights to view the court data. Let's say a battered wife has moved
to a new address she wants to keep secret for safety. She files a
case with the court for a temporary restraining order, prohibiting
the husband from coming near her. The court needs her address for
the official record, but the judge will order the address "sealed"
so that only people with a certain authority can see it. The
authority is very limited, for obvious reasons.

It is quite likely that the person initially entering the address
and flagging it as sealed will not have authority to see the
address if they go back and look up the case. Neither will the
dozens of other people making the same kind of entries in the
county. Obviously, if the person doing the initial entry is a
friend of the husband, the data is compromised; but not allowing
entry of the data in a state sealed by people without authority to
look it up exposes the data to every other person with entry
authority, with fairly obvious risks.

The more secure behavior is to allow entry of data which will not
be visible by the person doing the entry.

-Kevin



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: FDW: ForeignPlan and parameterized paths
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Review of Row Level Security