|Subject||Re: [Firebird-Architect] External engines - security|
> Roman, can we provide safe configuration to be used with firebird? I supposeYes.
> yes, that's why calling later Java 'safe' language.
> Discussion about security of external engines happened to move into Java-onlyI'd go this way. If somebody is needing a flexible language for stored
> direction. But initially we were going to provide access to definitely
> insecure languages, like Delphi. I'm not sure, have we found acceptable
> solution, or not. I see 2 main approaches:
> 1. Deal with it exactly like we do with UDFs (which certainly can send spam
> and provide other undesired activity if written that way). But due to limited
> access to them this it is not a security problem now.
procedures, he would have to choose between safe and slow Java (slow not
because it's Java, but because security checks take some time and
"context" switching between server and Java code takes some time) and
between faster but unsafe Delphi or C++ procedures.
> 2. Invent an approach, making it possible to safely store Delphi modules (alsoAgree.
> UDF - what's a difference?) directly in a database and use them.
> Looks like the only use in storing unsafe modules in a database is an ability
> to store them in a same form as safe one (PSQL, Java). But in all the rest
> aspects we have more disadvantages then advantages. If we already store some
> modules in a special directory of filesystem any database owner can easily
> use them in his database. That's false for per-database stored modules - to
> use them one need to contact SYSDBA. To store own modules on a disk one need
> to contact server admin, but is it much harder compared with contacting
> Therefore I suggest not to re-envent the wheel, trying to replace FS security
> with our own. We must say, that we have safe languages (currently PSQL and
> Java), that are free to be used by anyone with appropriate access to
> database. We keep (for backwards compatibility) UDFs, we may even add unsafe
> (Delphi, C++) general modules if we really need one. But they will follow the
> same rules as UDF.