[Pljava-dev] threads left running after function end

Off list I was asked about threads left running after the main function
returns. It's a pretty general question and I found what looks to be a
pretty serious security hole, so I figured I'd include the list as well.

If a function starts up a thread and doesn't wait for it to complete
before it returns, that thread is left running. It isn't allowed to
call anything on the server because the server is off doing other work
and it is not thread safe. So if the created thread tries to do a
database query it will block until the next call into a pljava function
happens at which point it can access the database again (until that
function returns). If the thread isn't doing database work it will run
until the database connection is closed at which point it will be
stopped as the JVM shuts down.

What I've discovered is that a thread which is left running after a call
to a trusted java function will then no longer be sandboxed if a call to
an untrusted function is made. So if you've created an untrusted
function as security definer and granted execution on that to an
unprivileged user they can take advantage of that and get superuser
access by leaving a thread running in a trusted function.

The original question was about making a function wait for all threads
before returning and this is possible now by simply altering the user
code to do something like:

private static void waitForAllThreads()
{
while (Thread.activeCount() > 1) {
Thread allThreads[] = new Thread[Thread.activeCount()];
int active = Thread.enumerate(allThreads);
for (int i=0; i<active; i++) {
// Don't need to wait for ourselves.
if (allThreads[i] == Thread.currentThread())
continue;

try {
allThreads[i].join();
} catch (InterruptedException ie) {
}
}
}
}

Should pljava force all threads to complete before returning though? I
can see the utility of creating a thread to bind to a tcp/ip socket and
wait for external data and queue that up for a later function call to
pickup from the thread for database processing. If you kept the
function call active over the entire lifetime of this service, you'd
have a very long transaction that would cause other problems (vacuum).
Although I suppose with a polling caller you'd need a program to do
that, so you might as well have the client bind to a socket and wait for
data instead. But I digress, your thoughts...

Kris Jurka