> Vlad Khorsun escreveu:
> >>> We have no agreement java classes must be stored inside DB.
> >>>
> >>>
> >> It doesn't matter.
> >>
> >
> > It does matter :
> >
> >
> >> System classes will certainly be in filesystem and users classes may be
> >> in filesystem or blob.
> >>
> >
> > how user classes come into the blob\file system ?
> >
> This is plugin responsabillity.

And its forced us to re-invent many wheels already implemented at filesystem
security level

> That's one task for DBMS_JAVA-like package that I want in FB.

Take some ideas from other DBMSs is a good practice. But only when we
take really good ideas ;) Or i can said another - not all things good for Oracle
good for Firebird also ;)

I just don't want to make FB more complex that it absolutely needed.

My point is that this is sysadmin's responsibility to not let suspect code
into his system

> >> 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.
> >>
> >
> > Sorry i see no direct analogue with SQL engine
> >
> It's analogue when you consider the ISP case, i.e., server is not from you.

What is "site" in your analogue ? OCX == external code (non SQL procedure),
computer == computer ;) applets == external code (non SQL procedure) but what
is a "site" ? And applets executed in\by browser (== firebird ?), not in computer.

> >> 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).
> >>
> >
> > It can't save to filesystem if host process is not allowed to do it
> >
> But it runs in fbserver space, no? How can fbserver be allowed to write
> to filesystem then?

In properly tuned system fbsever allowed to write at very limited palces in FS.
And only sysadmin know where this places are. And sysadmin may change it
as he(she) needed. Any other code executed inside fbserver don't know this
places too. Thus it can't write into FS

> >> 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.
> >>
> >
> > So J2SE security may (dis)allow to do it for fbserver.exe ?
> Sorry, but I'm not understand your question about J2SE security and
> fbserver.exe.

Can one tune J2SE security on per-process basis ? I.e. - allow some process
to do something (load java class and run it, for example). Or how it is worked ?

Regads,
Vlad