2013/9/4 Kevin Grittner <kgrittn@ymail.com>:
> Robert Haas <robertmhaas@gmail.com> wrote:
>> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas <robertmhaas@gmail.com> writes:
>
>>>> IMHO, this new feature should be similarly simple: when an
>>>> unprivileged user references a table, treat that as a reference
>>>> to a leakproof view over the table, with the RLS qual injected
>>>> into the view.
>>>
>>> And for insert/update/delete, we do what exactly?
>>
>> The same mechanism will prevent UPDATE and DELETE from seeing any
>> rows the user shouldn't be able to touch.
>
> +1
>
>> Simon and Greg are arguing that when an INSERT or UPDATE happens,
>> we ought to also check that the NEW row matches the RLS qual. I
>> don't find that to be terribly important because you can
>> accomplish the same thing with a per-row trigger today; and I
>> also don't think everyone will want that behavior.
>
> As an example from my Wisconsin Courts days, source documents come
> in which need to be entered, which may contain a Social Security
> Number, and most of the Clerk of Courts staff should be authorized
> to enter that into the database. Once it is entered, most people
> should not be allowed to view it, including many of the people who
> were authorized to enter it initially. It's one thing for a line
> staff person to have a handful of documents come across their desk
> with SSN on a given day; it's quite another if they could dump a
> list of names, addresses, dates of birth, and SSNs for the entire
> database on demand.
>
> In a way this issue is similar to the covert channel issue --
> volume matters.
>
I think an important nature of this behavior is it is configurable.
In case when both of reader and writer side need to have same
security policy, it's good. One configuration allows to apply
a consistent security policy to fetch a row from table, and to
write a row to table.
If they don't want to check security policy on writer side,
all they need to do is setting a security policy for SELECT
only, even though its functionality is not implemented yet.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>