|Subject||Re: [Firebird-Architect] External engines - metadata|
> >>>> If Java security manager may give disk access permissions to classesAbove _is_ security. I.e. this is sysadmin's responsibility to defend his
> >>>> 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.
> Now we have a database admin creating a database and he decides that heAbove is i don't know what ;) It have nothing common with _system_'s security
> 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.
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) andWell, if this would be part of Java-plugin and engine will have no built-in knowledge
> 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).
about it i see no reason to object ;)