From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751540AbcFXP7U (ORCPT ); Fri, 24 Jun 2016 11:59:20 -0400 Received: from h2.hallyn.com ([78.46.35.8]:43306 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750972AbcFXP7S (ORCPT ); Fri, 24 Jun 2016 11:59:18 -0400 Date: Fri, 24 Jun 2016 10:59:16 -0500 From: "Serge E. Hallyn" To: Tejun Heo Cc: Topi Miettinen , linux-kernel@vger.kernel.org, luto@kernel.org, serge@hallyn.com, keescook@chromium.org, Jonathan Corbet , Li Zefan , Johannes Weiner , Serge Hallyn , James Morris , Andrew Morton , David Howells , David Woodhouse , Ard Biesheuvel , "Paul E. McKenney" , Petr Mladek , "open list:DOCUMENTATION" , "open list:CONTROL GROUP (CGROUP)" , "open list:CAPABILITIES" Subject: Re: [PATCH] capabilities: add capability cgroup controller Message-ID: <20160624155916.GA8759@mail.hallyn.com> References: <1466694434-1420-1-git-send-email-toiwoton@gmail.com> <20160623213819.GP3262@mtj.duckdns.org> <53377cda-9afe-dad4-6bbb-26affd64cb3a@gmail.com> <20160624154830.GX3262@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160624154830.GX3262@mtj.duckdns.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Tejun Heo (tj@kernel.org): > Hello, > > On Fri, Jun 24, 2016 at 12:22:54AM +0000, Topi Miettinen wrote: > > > This doesn't have anything to do with resource control and I don't > > > think it's a good idea to add arbitrary monitoring mechanisms to > > > cgroup just because it's easy to add interface there. Given that > > > capabilities are inherited and modified through the process hierarchy, > > > shouldn't this be part of that? > > > > With per process tracking, it's easy to miss if a short-lived process > > exercised capabilities. Especially with ambient capabilities, the parent > > process could be a shell script which might not use capabilities at all, > > but its children do the heavy lifting. > > But isn't being recursive orthogonal to using cgroup? Why not account > usages recursively along the process hierarchy? Capabilities don't > have much to do with cgroup but everything with process hierarchy. > That's how they're distributed and modified. If monitoring their > usages is necessary, it makes sense to do it in the same structure. That was my argument against using cgroups to enforce a new bounding set. For tracking though, the cgroup process tracking seems as applicable to this as it does to systemd tracking of services. It tracks a task and the children it forks.