Re: WITH CHECK and Column-Level Privileges

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WITH CHECK and Column-Level Privileges
Date: 2014-10-30 08:19:46
Message-ID: CAEZATCU5SCZyhz7C4KxCct1UR9y02ALs1Ur1+bRns5vbpKHNGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29 October 2014 13:04, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Wed, Oct 29, 2014 at 8:16 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> > suggestions. If the user does not have table-level SELECT rights,
>> > they'll see for the "Failing row contains" case, they'll get:
>> >
>> > Failing row contains (col1, col2, col3) = (1, 2, 3).
>> >
>> > Or, if they have no access to any columns:
>> >
>> > Failing row contains () = ()
>>
>> I haven't looked at the code, but that sounds nice, except that if
>> they have no access to any columns, I'd leave the message out
>> altogether instead of emitting it with no useful content.
>
> Alright, I can change things around to make that happen without too much
> trouble.
>

Yes, skim-reading the patch, it looks like a good approach to me, and
also +1 for not emitting anything if no values are visible.

I fear, however, that for updatable views, in the most common case,
the user won't have any permissions on the underlying table, and so
the error detail will always be omitted. I wonder if one way we can
improve upon that is to include the RTE's modifiedCols set in the set
of columns the user can see, since for those columns what we would be
reporting are the new user-supplied values, and so there is no
information leakage.

Regards,
Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Szymon Guz 2014-10-30 08:30:07 Re: printing table in asciidoc with psql
Previous Message Michael Paquier 2014-10-30 08:19:01 Re: REINDEX CONCURRENTLY 2.0