All,

I never said we should try to limit machine code, where do you read it?

I'm saying just the contrary, since we can't do this but want usable (as
PSQL) Java procedures, we need server permissions to define external
procedures per language.

GRANT USAGE ON LANGUAGE JAVA TO USER NORMAL_USER1 WITH GRANT OPTION;
GRANT USAGE ON LANGUAGE DELPHI TO USER SUPER_USER1;


Adriano


Roman Rokytskyy escreveu:

>> Roman, limiting ability of server security now means we never be able to
>> do non-limited things or we should deal with backward compatibility in
>> the future.
>>
>
> I do not want to limit the capabilities of the server. But when you
> execute a native code, you loose control over the things (you jump to a
> particular instruction in your address space, it is up to the executed
> code whether to return you the control or not). I'd be very interested
> in hearing how to execute some native code in a sandbox mode without
> embedding a debugger into the server.
>
> And that's exactly what Alex wrote and what I agreed to - move the
> responsibility to decide what native code will be executed in the server
> to the sysadmin (he should decide whether allow a DLL to be copied into
> some particular directory or not).
>
> Also this has nothing to do with the server/engine, since a
> configuration file where the safe DLL locations are specified should
> belong to a Delphi/C++ language plugin. The server/engine takes care of
> its own business: checking the grants before calling a routine and
> translating the data between plugin and internal structures.
>
> Roman
>
> <sarcastic on>
> P.S. Ok, I know about one more possibility - each DLL with procedures
> will be signed and we will establish a CA and charge money for analysing
> the sources, building the code and signing it with our certificate.
> After that it can be deployed in production (we can then also sell
> production servers that would check the signatures).
> </sarcastic on>
>