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
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 |