Subject | Re: [Firebird-Architect] External engines - security (was: metadata) |
---|---|
Author | Vlad Khorsun |
Post date | 2007-10-19T12:31:06Z |
> Vlad Khorsun escreveu:It does matter :
> >> 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 behow user classes come into the blob\file system ?
> in filesystem or blob.
> > Another reason to integrate J2SE security with database users/roles inSorry i see no direct analogue with SQL engine
> > > 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 inIt can't save to filesystem if host process is not allowed to do it
> >> 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:So J2SE security may (dis)allow to do it for fbserver.exe ?
> > > 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.
Regards,
Vlad