Re: SCO: "thread creation is about a thousand times faster than on native Linux"

From: Stephen C. Tweedie (sct@redhat.com)
Date: Thu Aug 24 2000 - 10:36:52 EST


Hi,

On Thu, Aug 24, 2000 at 02:01:55PM +0200, Andi Kleen wrote:

> Here is my braindump. I would appreciate any comments.
>
> For good behaviour you need a shared sigprocmask().

Eek. If you are using any form of semaphore-based locking to protect
certain data structures in your threaded app, and if you need access
from inside signal handlers, then you _really_ need to be able to
disable signals on a per-thread basis to cope with critical sections.
Sure, you could do it on all threads, but that's unnecessaily
expensive and may impact signal response latency very badly.

> Another thing would be shared credentials. I'm sure there are portd
> programs who have security bugs on Linux because they expect setuid() to be
> process global, and it is local. Unfortunately that's more ugly to get right,
> you would need separate reference counted credentials structures to get
> atomic behaviour for system calls (they cannot see half changed credentials
> or eat credentials changes after sleeping).

... which is exactly why shared credentials are the work of the devil.
:) You _can_ do this in user space by signalling each process to
change its uid, in theory. However, if you enforce it in the kernel
then you prevent applications from playing tricks like setting the
fsid to the client uid for each request in a threaded server --- you
really need the different threads to be able to maintain different
fsids there.

I'd much rather see us do the sensible credential stuff in the
kernel, and the really, really broken bits of the API like shared
setuid in user space.

Cheers,
 Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:13 EST