[lkml]   [2008]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] How to handle the rules engine for cgroups
    Hi Vivek,

    On Tue, Jul 1, 2008 at 12:11 PM, Vivek Goyal <> wrote:
    > - netlink is not a reliable protocol.
    > - Messages can be dropped and one can loose message. That means a
    > newly forked process might never go into right group as meant.

    One way that you could avoid the unreliability would be to not use
    netlink, but instead use cgroups itself.

    What we're looking for is a way to easily distinguish between
    processes that are in the right cgroups, and processes that might be
    in the wrong cgroups. Additionally, we want the children of such
    processes to inherit the same status until we've dealt with them, and
    not be able to change their status themselves.

    That sounds a bit like a cgroup. How about the following?

    - create a cgroup subsystem called "setuid".

    - have a uid_changed() hook called by sys_setuid() and friends; this
    hook would simply attach current to the root cgroup in the "setuid"
    hierarchy if it wasn't already in that cgroup (which can be determined
    with a couple of dereferences from current and no locking, so not
    slowing down the normal case).

    - userspace uses this by:

    mount the setuid hierarchy, e.g. at /mnt/setuid
    create a child cgroup /mnt/setuid/processed
    while true:
    wait for /mnt/setuid/tasks to be non-empty
    read a pid from /mnt/setuid/tasks
    move that pid to the appropriate cgroups in memory/cpu/etc
    hierarchies if necessary
    move that pid to /mnt/setuid/processed/tasks

    i.e. any pid in the root cgroup of the setuid hierarchy is one that
    needs attention and may need to be moved to different cgroups

    A couple of enhancements to make this more usable might include:

    - adding an API (via a new syscall or an eventfd?) to wait for a
    cgroup to be non-empty, to avoid having to poll /mnt/setuid/tasks more
    than necessary

    - allow the user to designate certain processes and their children as
    uninteresting so that their setuid calls don't trigger them being
    moved back to the root (perhaps indicated via membership of an
    "ignored" cgroup in the setuid hierarchy?)

    This should be more reliable than netlink since it doesn't involve
    userspace having to keep up with a stream of events - we're not
    queuing up events, we're just shifting process group memberships.

    Similar approaches could be used for a "setgid" hierarchy and an
    "execve" hierarchy.


     \ /
      Last update: 2008-07-10 11:09    [W:0.022 / U:17.808 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site