Re: WITH CHECK and Column-Level Privileges - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: WITH CHECK and Column-Level Privileges
Date
Msg-id CAEZATCU5SCZyhz7C4KxCct1UR9y02ALs1Ur1+bRns5vbpKHNGw@mail.gmail.com
Whole thread Raw
In response to Re: WITH CHECK and Column-Level Privileges  (Stephen Frost <sfrost@snowman.net>)
Responses Re: WITH CHECK and Column-Level Privileges
List pgsql-hackers
On 29 October 2014 13:04, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Wed, Oct 29, 2014 at 8:16 AM, Stephen Frost <sfrost@snowman.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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: REINDEX CONCURRENTLY 2.0
Next
From: Szymon Guz
Date:
Subject: Re: printing table in asciidoc with psql