lkml.org 
[lkml]   [2001]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    On Tue, 16 Jan 2001, Ingo Molnar wrote:

    > But even user-space code could use 'native files', via the following, safe
    > mechanizm:

    so here's an alternative to ingo's proposal which i think solves some of
    the other objections raised. it's something i've proposed in the past
    under the name "extended file handles".

    struct extended_file_permission {
    int refcount;
    some form of mutex to protect refcount;
    some list structure head;
    };

    struct extended_file {
    struct file *file;
    struct extended_file_permission *perm;
    whatever list foo is needed to link with extended_file_perm above;
    };

    if you allocate a few huge arrays of struct extended_file, then you can
    verify if a pointer passed from user space fits into one of those arrays
    pretty quickly.

    struct task has a struct extended_file_permission * added to it to
    indicate which perm struct that task is associated with.

    so you just compare the f->perm to current->extended_file_perm and you
    know if the task is allowed to use it or not.

    clone() allows you to create tasks sharing the same
    extended_file_permissions.

    fork()/exec() would create new extended_file_perms -- which implicitly
    causes all those files to be closed. this gives you pretty light cgi
    fork()/exec() off a main "process" which is handling thousands of sockets.

    i also proposed various methods of doing O_foo flag inheritance... but the
    above is more interesting.

    -dean

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:22    [W:0.022 / U:30.732 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site