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
|
Список | 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 по дате отправления: