Re: Specification for Trusted PLs?
От | Tom Lane |
---|---|
Тема | Re: Specification for Trusted PLs? |
Дата | |
Msg-id | 23186.1274472278@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Specification for Trusted PLs? (Joshua Tolley <eggyknap@gmail.com>) |
Ответы |
Re: Specification for Trusted PLs?
Re: Specification for Trusted PLs? Re: Specification for Trusted PLs? |
Список | pgsql-hackers |
Joshua Tolley <eggyknap@gmail.com> writes: > 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 s/untrusted/trusted/ here, right? > launch_missiles()". To me, as long as they go back into the database via SPI, anything they can get to from there is OK. What I meant to highlight upthread is that we don't want trusted functions being able to access other functions "directly" without going through SQL. As an example, a PL that has FFI capability sufficient to allow direct access to heap_insert() would have to be considered untrusted. regards, tom lane
В списке pgsql-hackers по дате отправления: