lkml.org 
[lkml]   [2015]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [Workman-devel] cgroup: status-quo and userland efforts
    Date
    Serge Hallyn <serge.hallyn@...> writes:

    >
    > Quoting Daniel P. Berrange (berrange@...):

    > > Are you also planning to actually write a new cgroup parent manager
    > > daemon too ? Currently my plan for libvirt is to just talk directly
    >
    > I'm toying with the idea, yes. (Right now my toy runs in either native
    > mode, using cgroupfs, or child mode, talking to a parent manager) I'd
    > love if someone else does it, but it needs to be done.
    >
    > As I've said elsewhere in the thread, I see 2 problems to be addressed:
    >
    > 1. The ability to nest the cgroup manager daemons, so that a daemon
    > running in a container can talk to a daemon running on the host. This
    > is the problem my current toy is aiming to address. But the API it
    > exports is just a thin layer over cgroupfs.

    cool! that's funny, that sounds exactly like what i asked if you
    could provide, and it turns out that you already did :)

    so, in theoorryy..... you could have this:

    * run the service on top of /dev/cgroups, republishing [a subset?] as
    /run/cgroups and some other parts as /run/cgroups2

    * have PID1, instead of going directly to /dev/cgroups, to go to
    /run/cgroups *instead*.

    * have lxc, instead of going directly to /dev/cgroups, to go to
    /run/cgroups2 *instead*.

    the problem: as lennart mentions, PID1s such as systemd may be expecting
    to manage the setup of cgroups - entirely - for security or other
    initialisation reasons - *before* even the service that you've created,
    serge, is allowed to run.

    and *that's* why i suggested the idea of following what SE/Linux has
    done, which is to have policy files that compile down to a set of
    permissions that the (various) managers can and cannot do. bits of
    cgroup that they are and are not permitted to manage.

    flat at the kernel implementation level; hierarchical (or other)
    at the "compile-the-policy-file" level.

    l.



    \
     
     \ /
      Last update: 2015-03-03 23:41    [W:4.201 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site