Re: pl/pgsql enabled by default
От | Mike Mascari |
---|---|
Тема | Re: pl/pgsql enabled by default |
Дата | |
Msg-id | 427D7E34.6040300@mascari.com обсуждение исходный текст |
Ответ на | Re: pl/pgsql enabled by default (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: pl/pgsql enabled by default
Re: pl/pgsql enabled by default |
Список | pgsql-hackers |
Andrew Dunstan wrote: > > > Mike Mascari wrote: > but the side effect function will only run (unless you set it with > security definer) with the privileges of the caller - it won't grant > visibility to things that user can't otherwise see. If the visibility is determined by view definitions, such as using CURRENT_USER, which is an exceedingly common practice, then the caller will be able to record tuples before they are filtered by the executor. > In any case, you should define your security setup with the > capabilities / limitations of the db engine in mind. If there is any > security problem in your scenario, it is that you appear to have made > unwarranted assumptions about how postgres works, rather than that > postgres has a problem. I think most people coming from any other enterprise-class RDBMS environment will be surprised that they cannot use VIEWs to provide user-specific views on data. I could be wrong, but I'd put money on it... > Either way, this does not illustrate how enabling plpgsql by default is > a security risk. Correct, as the vulnerability exists within the 'SQL' language as well. The only difference is that enabling plpgsql by default changes it from a leak to a full blown flood. Mike Mascari
В списке pgsql-hackers по дате отправления: