RE: gcj crashes if a user-thread gives up its rights

["Boehm, Hans" <hans dot boehm at hp dot com>]

> From: Jost Boekemeier [mailto:jost2345@yahoo.de]
> > to do what you want (pthread_setuid_np()?). 
> 
> Well, I don't insist on the non-posix behaviour.
> All user-threads are not a problem either, because
> they are started from my pool which does the right
> things.
> 
> The problem is the one gc/gcj "system thread" which I
> don't control. 
I suspect there may be several such threads, depending
on how things are configured.

It still seems to me that the only technical solutions here
that make sense are:

1) Fix Linux/NPTL setuid().  Then change the uid  of the
entire process, and live with the results of that.  I
think that at that point the gc and libgcj probably just
work.  And this is where we want to get eventually,
because the applicable standard requires it.

2) Rely on Java security managers instead of uids.

It still seems to me that adding a workaround to the
GC to sort of let you take advantage of an NPTL bug
isn't a good solution.

If someone wants to propose a patch which always runs
the GC from a single thread, and is justifiable on other
grounds, I'd certainly consider it.  But my guess is
that this will complicate the code more than is otherwise
justifiable. 
> 
> 
> > And for non-Java code, it would be trivial
> > to just hijack another thread.
> 
> How?  That exactly would be the solution to my
> problem: I cannot change the uid for the gcj "system
> thread". -- What does this thread do, btw?  I assumed
> that it is either the GC or a mediator which works for
> the GC.
> 
Sorry.  I meant it would be trivial for malicious code
to run code in an unrestricted thread, e.g. by overwriting
a vtable entry somewhere.  Hence you still have to trust
the code in the restricted thread.  But given that we're
talking about C or C++ code, that's not a profound
observation.

I'm not sure that this gives you a reliable and clean way
to run code in all of the system threads, especially if they
happen to be blocked.
> 
> > nptl source [...] still seems to rely on signals for
> a few things
> 
> I've had the impression that this is only used to
> cancel a thread or other things that I don't expect to
> work when my thread doesn't have the rights.
> 
Based on a cursory look at the source, I think that's mostly
right, though I suspect that something like exit() wouldn't
work either, and would leave things in a messy state.

Hans