|Subject||Re: [Firebird-Architect] External engines - security|
> Roman, limiting ability of server security now means we never be able toI do not want to limit the capabilities of the server. But when you
> do non-limited things or we should deal with backward compatibility in
> the future.
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.
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).