Re: Specification for Trusted PLs?
От | Joshua Tolley |
---|---|
Тема | Re: Specification for Trusted PLs? |
Дата | |
Msg-id | AANLkTiliUTrhqI5zDMTnA0PnvgItzaFCSeQtiHncRhZr@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Specification for Trusted PLs? (David Fetter <david@fetter.org>) |
Ответы |
Re: Specification for Trusted PLs?
|
Список | pgsql-hackers |
On Fri, May 21, 2010 at 1:36 PM, David Fetter <david@fetter.org> wrote: > On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote: >> As long as you can't do database access except via SPI, that should >> be covered. So I guess the next item on the list is no, or at least >> restricted, access to functions outside the PL's own language. > > "No access" seems pretty draconian. > > How about limiting such access to functions of equal or lower > trustedness? Surely an untrusted function shouldn't be restricted > from calling other untrusted functions based on the language they're > written in. Agreed. As long as a trusted language can do things outside the database only by going through a database and calling some function to which the user has rights, in an untrusted language, that seems decent to me. A user with permissions to launch_missiles() would have a function in an untrusted language to do it, but there's no reason an untrusted language shouldn't be able to say "SELECT launch_missiles()". -- Joshua Tolley / eggyknap End Point Corporation
В списке pgsql-hackers по дате отправления: