On Thu, Aug 24, 2000 at 04:36:52PM +0100, Stephen C. Tweedie wrote:
> 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.
Stephen, read the whole paragraph, I covered that ;)
Even POSIX got that (pthread_sigmask), just you additionally want a global
masking to make signals useful (otherwise lots of programs have to invent
their own signal locking). In the kernel it could be done without too
much pain (first check thread local mask and then check shared mask in
signal_struct)
>
> > 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.
It would be of course be optional, I agree that it makes a lot of sense
for programs to not share credentials between threads if they wish so. It
is just broken for an POSIX Threads environment, because it silently
introduces security holes into ported software.
> 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.
I just have a hard time imagining a sane way to do it in user space.
Do you have a good idea how it would work?
-Andi
-
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