> >>>> If Java security manager may give disk access permissions to classes
> >>>> by its name, why do we need to integrate (read - re-invent) this functionality
> >>>> into FB ?
> >>>>
> >> Vlad, we didn't need to reinvent anything.
> >>
> >> We just need a way to configure Java security though the database,
> >> instead of editing JVM configuration files.
> >
> > Why though the database ??? Give me a reasons, please
>
> Consider the case of ISP. The sysadmin defines permissions common for
> all databases (read users) of the system. For example it defines that
> each database can do something on the file system in user home directories.

Above _is_ security. I.e. this is sysadmin's responsibility to defend his
_system_

> Now we have a database admin creating a database and he decides that he
> gives a possibility to deploy new Java procedures to Ann (should be
> handled via something like GRATE CREATE PROCEDURE), but the procedures
> should be able to access files only in a particular directory.

Above is i don't know what ;) It have nothing common with _system_'s security
as real _system_'s security already defined by sysadmin. I.e. if sysadmin allow
to java programs to send spam then there are no guarantee that dbadmin will
take care about it. And if sysadmin disallow to java programs to send spam
then no dbadmins can do it.

> So, you need both - one "per-server" configuration (can be a file) and
> per-database (either via database or file). Database looks more natural
> (but at the same time I object to extend our DDL/DML commands -
> management procedures exported by plugin should be enough).

Well, if this would be part of Java-plugin and engine will have no built-in knowledge
about it i see no reason to object ;)

Regards,
Vlad