Jim Starkey <jas@...> wrote:

>It probably could be done. But that isn't the point. UDF's have
>always been a liability from the perspective of reliability and
>security.

This reads to me like a reordering of priorities. In your first message,
you wrote: "The sandbox model is attractive, but the (theoretical) ability
to install or replace UDFs while the server is running would be absolutely
wonderful."

The point of my response was to point out that UDF replacement is possible
without going to the extent of a JVM.

> ... Loading an executing an arbitrary library, even one
>more or less vetted by the DBA, is scary. A UDF can write over
>memory, break security, trash records, corrupt databases, and
>anything else it's evil little heart desires. The concept of
>a UDF exchange is unthinkable. Who in their right mind is going
>to stick unknown code in the guts of their mission critical
>database server? Certainly not somebody smart enough to use
>Interbase.

I agree that sandboxing is a Good Thing(tm), and I've pointed out a number
of times in the past that the presence of UDFs (as they currently exist)
makes it very difficult to secure an IB server.

A few specific points:

- I don't see that UDF exchange in this context is unthinkable, given
appropriate permissions. I can't see that whether it is native object code
or Java bytecode makes any difference.

- Obviously random users shouldn't be able to replace (or install) a UDF,
regardless of whether it is object code, byte code, or whatever.

- Native object code UDFs do not have to be unvetted. Clearly, you have to
trust the output of the compiler unless you want to go to a lot of effort.
I've see more crashes and corruption from Interbase itself than I have from
any UDF. That could be because I don't use any UDFs (although I am planning
to try them out for collation of calculated fields).

>A Java function is completely safe. It runs in a controlled
>sandbox and cannot see anything that is not passed to it or
>declared as a public class level static variable, and even
>that can be controlled by a suitably paranoid VM.
>
>The advantages of Java UDFs, blob filters, and possibly stored
>procedures are so great that I don't think it makes sense extending
>the old, insecure, native UDF mechanisms.

Sounds like you've caught Java Religion. Hopefully you'll get over it. :-)

Seriously though, I see the value of sandboxes, but I don't see the value of
Java other than tools availability. While development tools are useful,
they aren't the only part of the decision.

Even the Interbase stored procedure language could be extended. BLR runs in
a sandbox. The database itself could be used to provide storage for state
information between UDF invocations, which would be much cleaner than the
Java model.

SQL/PSM might be an option, although I must confess to not having taken the
time to read the standard yet.

Jan Mikkelsen
janm@...