Re: Row-security writer-side checks proposal

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Row-security writer-side checks proposal
Date: 2013-11-12 14:35:21
Message-ID: CA+TgmoZPBSgcr=XD=pjUEptP2+h34nnM3MA-_55u-qqCob+J+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 9, 2013 at 10:01 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 11/08/2013 11:03 PM, Robert Haas wrote:
>>> > Separate "READ DELETE" etc would only be interesting if we wanted to let
>>> > someone DELETE rows they cannot SELECT. Since we have DELETE ...
>>> > RETURNING, and since users can write a predicate function for DELETE
>>> > that leaks the information even if we didn't, in practice if you give
>>> > the user any READ right you've given them all of them. So I don't think
>>> > we can support that (except maybe by column RLS down the track).
>>
>> Well, we could require SELECT privilege when a a RETURNING clause is present...
>
> Absolutely could. Wouldn't stop them grabbing the data via a predicate
> function on the update/delete, though, and we can't sanely (IMO) require
> SELECT rights if they want to use non-LEAKPROOF functions/operators either.

Hmm, good point.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-11-12 14:38:22 Re: Clang 3.3 Analyzer Results
Previous Message Robert Haas 2013-11-12 14:34:46 Re: Postgresql c function returning one row with 2 fileds