Subject Re: [Firebird-Architect] External engines - security
Author Vlad Khorsun
> Adriano dos Santos Fernandes wrote:
> > Jim Starkey escreveu:
> >
> >> Everyone understands what it means to add support for external
> >> procedures via a plugin or an embedded JVM, but I don't understand why
> >> you are concerning yourself with security characteristics of the Java
> >> language, classes, or virtual machine.
> >>
> > Jim, there are many discussion about various things, but more
> > controversy IMHO is that Vlad said Java and Delphi/C external procedures
> > should have same security privileges for one being able to
> > define/declare external procedures.
> >
> > This is unacceptable IMHO, as Java may be safe and Delphi/C code is not.
> >
> > Ok, if I can't put a Delphi/C module in the server I can't use it and
> > then it's safe.
> >
> > Our current UDF security (as well our security in general) is very
> > limited, let's invent something better.
> >
> >
> Inventing something better might be the right answer, but is premature.
> Vlad, what problems were you trying to solve by proposing additional
> security requirements for defining external procedures? I'm not arguing
> that there aren't problems, but a potential solution must be evaluated
> against the problem it is intended to solve.

Oh. There was many misunderstanding in this thread. Below i try to
summarise all i have seen here :

1. Adriano proposed to implement some Java-specific security management
through database engine. At least this is how i understand it, probably wrong.
I object to add any Java (or .Net, or Delphi, etc) specific features into engine.

2. Adriano proposed to implement GRANT USAGE ON <LANGUAGE> TO <USER>.
This permission allows to create and modify procedures on specified language.
By default all users are granted to use only 'safe' languages (PSQL and Java).
Only SYSDBA (not the database OWNER) have by default permission to create
'unsafe' procedures and to grant it to another users.
When it became clear for me i stopped to object, while still not see it as necessary.