lkml.org 
[lkml]   [2006]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: The issues for agreeing on a virtualization/namespaces implementation.
    From
    Date
    Kyle Moffett <mrmacman_g4@mac.com> writes:

    > On Feb 07, 2006, at 17:06, Eric W. Biederman wrote:
    >> I think I can boil the discussion down into some of the fundamental questions
    >> that we are facing.
    >>
    >> Currently everyone seems to agree that we need something like my namespace
    >> concept that isolates multiple resources.
    >>
    >> We need these for
    >> UIDS
    >> FILESYSTEM
    >
    > I have one suggestion for this (it also covers capabilities to a certain
    > extent). Could we use the kernel credentials system to abstract away the
    > concept of a single UID/GID? We currently have uid, euid, gid, egid, groups,
    > fsid. I'm thinking that there would be virtualized UID tables to determine
    > ownership of processes/SHM/etc.
    >
    > Each process would have a (uid_container,uid) pair (or similar) as its "uid"
    > and likewise for gid. Then the ability to send signals to any given
    > (uid_container,uid) or (gid_container,gid) pair would be given by keys in the
    > kernel keyring indexed by the "uid_container" part and containing the "uid"
    > part (or maybe just a pointer).
    >
    > Likewise the filesystem access could be virtualized by using uid and gid keys
    > in the kernel keyring indexed by vfsmount (Not superblock, so that it would be
    > possible to have different UID representations on different mounts/parts of the
    > same filesystem).
    >
    > I'm guessing that the performance implications of the above would not be quite
    > so nice, as it would put a lot of code in the fastpath, but I would guess that
    > it might be possible to use the existing fields for processes without any
    > virtualization needs.

    At least for signal sending it looks like it would be easier to just compare
    the pointers to struct user. At least in that context it looks like it
    would be as cheap as what we are doing now. I just don't know where
    to find a struct user for the euid, or is it the normal uid.

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

    \
     
     \ /
      Last update: 2006-02-09 06:45    [W:2.948 / U:0.404 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site