lkml.org 
[lkml]   [1998]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: CLONE_PID (was Re: Potential Threads security bug with LinuxThreads)
    From
    Date
    Chris Wedgwood <chris@cybernet.co.nz> writes:
    > On Wed, Aug 26, 1998 at 11:08:41AM +0200, Andi Kleen wrote:
    > > Another thing it should do is to broadcast all uid/gid/euid etc.
    > > changes to all other threads that share the pid. Currently Linux
    > > has "per thread permissions", that differs from all other Unixes I
    > > know and it is a potential security problem.
    >
    > I know I'm totally naive and out of my depth here, but why can't we
    > just make whats current called a process thread, and have a common
    > process structure parenting each thread for 2.3.x?

    We could. It just happens to have been done in a piecemeal
    fashion. Eventually, setting all of the clone() flags will cause
    everything that should be "per-process" to be so. That fact that the
    per-porcess data will be kept in several structures, rather than one
    as you suggest, isn't particularly significant. And who knows, certain
    combinations of clone() flags might turn out to be useful.

    > Sure, this will break stuff - most of /proc and lots of other things.
    > But it would then allow true kernel threads, where signals were sent
    > to the threads structures parent, the process, etc.

    The problems with implementing threaded signals are the same whatever
    way you look at it: How to quickly select a thread to recieve a signal
    sent to the process, but also allowing threads to change their signal
    masks quickly. Where to put the pointer to whatever data structures
    are needed to implement this fast signal delivery is a minor issue.

    > It would also require moving stuff for getrusage, etc. into the
    > thread context in part, and leaving other parts in the process
    > context and on the whole make life rather nasty to start with.

    Yup. There are many bits and pieces to be dealt with. I think the
    important thing is to (hopefully in 2.3) build up some momentum
    towards a fully conformant POSIX threads implementation, and then take
    care of the useful bits and pieces outside the scope of POSIX (such as
    rusage, process/thread times, and comprehensible ps output).

    > Perhaps thread IDs and process IDs need to share the same namespace,
    > so where you get details on a process its the aggregate for all
    > threads for fields like CPU time?

    That seems like the most practical scheme to me, currently.

    > But, once this has been done, and big chunks of userland fixed, the
    > end result would be more elegant?

    --
    Dave Wragg

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:2.148 / U:0.892 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site