Adriano dos Santos Fernandes wrote:

> Jim Starkey wrote:
>
>> Adriano dos Santos Fernandes wrote:
>>
>>
>>> Roman Rokytskyy wrote:
>>>
>>>
>>>
>>>>> We'll not allow calls for non-registered methods directly from the database.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> See my recent post: a) you can't do it; b) you don't want to do it. :)
>>>>
>>>>
>>>>
>>> It seems we're each one misunderstand the others. :-)
>>>
>>> I mean, we'll not have something like this direct in PSQL:
>>> java_plugin_call('MyClass.myProcedure');
>>>
>>> I.e., call a non registered (in FB) external procedure.
>>>
>>> Though we can't and shouldn't prevent the user from write such external
>>> procedure that do this.
>>>
>>>
>>>
>>>
>> What do you hope to accomplish by this?
>>
> To accomplish what?
>
> In response to Vlad, I said "not have", but Roman was think I said
> another thing...
>
>

No, what is this whole line of discussion about? What are you trying to
achieve with the JVM?

A major consideration is what JVM. Firebird doesn't have one. Most
open source JVM are GPL, so you can't modify one. That pretty much
means you're going to have to take one off the shelf and load it
dynamically, so creating a new security model is out of the question.

The point is this: Internal Java security is about blocking access to
services from Java programs. It isn't about protecting the JVM (or a
program loading a JVM) from rogue "native" methods. If you think that
internal Java security is going to protect the server from native code,
you will need to learn more about Java.