Vlad Khorsun escreveu:

>> Plugin is DLL, but user code is classes.
>>
>
> We have no agreement java classes must be stored inside DB.
>

It doesn't matter.

System classes will certainly be in filesystem and users classes may be
in filesystem or blob.

> Another reason to integrate J2SE security with database users/roles in
> > the plugin.
>
>
> How J2SE security is worked ? Is it enough to (dis)allow execute some
> java code by fbserver.exe ?
>

We load Java through DLL and should load classes from different users in
different classloaders.
We them apply different security managers for these different classloaders.

I'm not expert on this, but it works more or less this way. :-)

I suppose you not allow any site to run OCX on your computer, but
applets may run on it.

And these applets can't read your disk, if you not choose to trust it.

>> If plugin allows to send binary data to blob and then execute what is in
>> the blob, it can.
>>
>
> For native code its called DEP - data execution prevention. And it have no
> relation with database engine security. I see no good reason to make exceptions
> for java or any other language

I'm not talking about execution of data segments, but in the case plugin
executing what is in blob in general (it can save to filesystem before
execution).

> Here is how this is handled in Oracle:
> > dbms_java.grant_permission('USER_NAME',
> > 'SYS:java.lang.RuntimePermission', 'getClassLoader', '' );
> >
> > So Java code in USER_NAME schema is allowed to call getClassLoader() method.
> >
> > We can do the same thing for users allowed and not allowed to send spam. :-)
>
>
> How its differ from GRANT <USER> EXECUTE ON <PROCEDURE> ?
>

GRANT applies to top-level execution only, i.e., what one have DECLAREd
and user can execute.

We have no control of function names inside classes, so we should not
use GRANT for it, but J2SE security that is just for it.


Adriano