Re: ExecutorCheckPerms() hook

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: ExecutorCheckPerms() hook
Дата
Msg-id 4BFC70BD.50305@ak.jp.nec.com
обсуждение исходный текст
Ответ на Re: ExecutorCheckPerms() hook  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: ExecutorCheckPerms() hook  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
(2010/05/25 22:59), Stephen Frost wrote:
> * KaiGai Kohei (kaigai@ak.jp.nec.com) wrote:
>> * DoCopy() and RI_Initial_Check() were reworked to call ExecCheckRTEPerms()
>>    with locally built RangeTblEntry.
> 
> Maybe I missed it somewhere, but we still need to address the case where
> the user doesn't have those SELECT permissions that we're looking for in
> RI_Initial_Check(), right?  KaiGai, your patch should be addressing that
> in a similar fashion..

The reason why user must have SELECT privileges on the PK/FK tables is
the validateForeignKeyConstraint() entirely calls SPI_execute() to verify
FK constraints can be established between two tables (even if fallback path).

And, the reason why RI_Initial_Check() now calls pg_class_aclcheck() is
to try to avoid unexpected access violation error because of SPI_execute().
However, the fallback path also calls SPI_execute() entirely, so I concluded
the permission checks in RI_Initial_Check() is nonsense.

However, it is an independent issue right now, so I kept it as is.

The origin of the matter is that we applies unnecessary permission checks,
although it is purely internal use and user was already checked to execute
whole of ALTER TABLE statement. Right?

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: ExecutorCheckPerms() hook
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: Synchronization levels in SR