[lkml]   [2007]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ckrm-tech] [PATCH 0/2] resource control file system - aka containers on top of nsproxy!
    "Paul Menage" <> writes:

    > On 3/7/07, Eric W. Biederman <> wrote:
    >> The real trick is that I believe these groupings are designed to be something
    >> you can setup on login and then not be able to switch out of.
    > That's going to to be the case for most resource controllers - is that
    > the case for namespaces? (e.g. can any task unshare say its mount
    > namespace?)

    With namespaces there are secondary issues with unsharing. Weird things
    like a simple unshare might allow you to replace /etc/shadow and thus
    mess up a suid root application.

    Once people have worked through those secondary issues unsharing of
    namespaces is likely allowable (for someone without CAP_SYS_ADMIN).
    Although if you pick the truly hierarchical namespaces the pid
    namespace unsharing will simply give you a parent of the current

    For resource controls I expect unsharing is likely to be like the pid
    namespace. You might allow it but if you do you are forced to be a
    child and possible there will be hierarchy depth restrictions.
    Assuming you can implement hierarchical accounting without to much

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-03-08 03:31    [W:0.027 / U:3.768 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site