|Subject||Re: [Firebird-Architect] External engines - metadata|
>>> Now we have a database admin creating a database and he decides that heFrom the ISP's point of view this is not security. And we talk here about ISP, isn't is ?
>>> 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.
> It is delegating the responsibility for some particular domain to the
> dbadmin. I see it as the same kind of security.
>>> So, you need both - one "per-server" configuration (can be a file) andWhile i can't agree its necessary i not object until all plugins are equal for
>>> 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 ;)
> You know my position on this topic - I want to let the plugin "define"
> the needed tables/procedures in the database on the first use.
engine. Each plugin as any other application may create its objects in database.
If it granted to do it ;)