Re: Re-enabling SET ROLE in security definer functions

Поиск
Список
Период
Сортировка
От Turner, Ian
Тема Re: Re-enabling SET ROLE in security definer functions
Дата
Msg-id 5D5C2F4B28E2514BBAB8E82572912B641C7E86361A@NYCMBX3.winmail.deshaw.com
обсуждение исходный текст
Ответ на Re: Re-enabling SET ROLE in security definer functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re-enabling SET ROLE in security definer functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Really?  What can it contain, and how are you enforcing that?

Anything except a function call. We look for non-keyword identifier followed by open parenthesis, which is probably
excessivelyrestrictive. I'd rather have something less kludgey, of course. This will also become a real nightmare if
newidentifier quoting approaches are introduced. 

>  Even more
> to the point, if you have managed to restrict it to the point where
> there's no possibility of someone executing a SET ROLE, why do you need
> any permissions switch at all?

We don't want to have to check access privileges on every object referenced by the statement, which (as I'm sure you're
aware)can get real nasty real quick. 

> That's isomorphic to claiming that it
> won't execute any SQL command at all, in which case you needn't worry about
> changing permissions.

Not sure what you mean here, can you elaborate?

--Ian


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re-enabling SET ROLE in security definer functions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re-enabling SET ROLE in security definer functions