Subject | Re: [Firebird-Architect] External engines - security |
---|---|
Author | Jim Starkey |
Post date | 2007-10-21T16:01:52Z |
Adriano dos Santos Fernandes wrote:
security, per se. Any plugin, JVM included, is a potential risk to
server integrity. However, if you trust the JVM, Java procedures are
not dangerous to database server integrity. They are, however, just as
dangerous to the ISP as any other code. If the Java code calls
dynamically loaded native code, however, all bets are off and the
distinction is without meaning.
> Postgree has multi-language for long time, and here explain how theyI suspect that this has more to do with server integrity than database
> work re. security:
> http://yaofeng.cdut.cn/postgre/7.3/sql-createlanguage.html
>
> There is TRUSTED and non-TRUSTED languages.
>
> Something about Informix:
> http://publib.boulder.ibm.com/infocenter/idshelp/v111/index.jsp?topic=/com.ibm.ddi.doc/ddi108.htm
>
> A mix of these two schemes seems perfect to me.
>
> External engine configuration file defines if language is trusted or not.
>
> For TRUSTED languages, database owner can ex:
> GRANT USAGE ON LANGUAGE JAVA TO user1 [WITH GRANT OPTION]
>
> For non-TRUESTED languages, only SYSDBA can do this.
>
>
security, per se. Any plugin, JVM included, is a potential risk to
server integrity. However, if you trust the JVM, Java procedures are
not dangerous to database server integrity. They are, however, just as
dangerous to the ISP as any other code. If the Java code calls
dynamically loaded native code, however, all bets are off and the
distinction is without meaning.