Re: WITH CHECK and Column-Level Privileges

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: WITH CHECK and Column-Level Privileges
Дата
Msg-id CAEZATCU5SCZyhz7C4KxCct1UR9y02ALs1Ur1+bRns5vbpKHNGw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WITH CHECK and Column-Level Privileges  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: WITH CHECK and Column-Level Privileges
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: REINDEX CONCURRENTLY 2.0
Следующее
От: Szymon Guz
Дата:
Сообщение: Re: printing table in asciidoc with psql