[Pljava-dev] threads left running after function end

[Kris Jurka]

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