Re: ExecutorCheckPerms() hook

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: ExecutorCheckPerms() hook
Дата
Msg-id 20100722010441.GI21875@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: ExecutorCheckPerms() hook  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Ответы Re: ExecutorCheckPerms() hook  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Список pgsql-hackers
* KaiGai Kohei (kaigai@ak.jp.nec.com) wrote:
> We can find out a similar case in CreateTrigger().
> If I was granted TRIGGER privilege on a certain table, I can create a new
> trigger on the table without its ownership. More commonly, it allows us
> to modify a certain property of the table without its ownership.

TRIGGER is hardly the same as REFERENCES.  If we invented a new priv, it
would be more like 'FK_CREATE'.

> Perhaps, if SQL permission would be more fine-grained, for example,
> "RENAME" permission might control RENAME TO statement, rather than
> its ownership.

This wouldn't actually be any more fine-grained, it'd just be adding
rights on to an existing priv, which I think is a wholly *bad* idea.

> What is the reason why we check its ownership here, although we already
> have REFERENCES permission to control ADD FOREIGN KEY?

REFERENCES is needed on the REFERENCED table, ownership is needed on the
REFERENCING table.  They're not the same..

We only allow owners of objects to change the structure of those
objects.  Adding a FK to another table doesn't really change the
structure of the referenced table.  Adding a FK does though, imv.
Thanks,
    Stephen

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: ExecutorCheckPerms() hook
Следующее
От: Robert Haas
Дата:
Сообщение: Re: ExecutorCheckPerms() hook