From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751172AbcGMGwp (ORCPT ); Wed, 13 Jul 2016 02:52:45 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:36640 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750780AbcGMGwf (ORCPT ); Wed, 13 Jul 2016 02:52:35 -0400 Subject: Re: [PATCH] capabilities: audit capability use To: Tejun Heo References: <1468235672-3745-1-git-send-email-toiwoton@gmail.com> <20160711170711.GB3337@htj.duckdns.org> <683cdbb9-c414-07c7-16d3-41c4138ddf8d@gmail.com> <20160712145936.GH3190@htj.duckdns.org> Cc: linux-kernel@vger.kernel.org, ebiederm@xmission.com, pmladek@suse.com, luto@kernel.org, serge@hallyn.com, keescook@chromium.org, Paul Moore , Eric Paris , Li Zefan , Johannes Weiner , "moderated list:AUDIT SUBSYSTEM" , "open list:CONTROL GROUP (CGROUP)" , "open list:CAPABILITIES" From: Topi Miettinen Openpgp: id=A0F2EB0D8452DA908BEC8E911CF9ADDBD610E936 Message-ID: <687b82c6-0e66-0ff1-30f1-a1d60f40f624@gmail.com> Date: Wed, 13 Jul 2016 06:52:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160712145936.GH3190@htj.duckdns.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/12/16 14:59, Tejun Heo wrote: > On Mon, Jul 11, 2016 at 07:47:44PM +0000, Topi Miettinen wrote: >> It's really critical to be able to associate a task in the logs to >> cgroups which were valid that time. Or can we infer somehow what cgroups > > When is "that time"? Without logging all operations, this is > meaningless. > >> a task was taking part, long time after task exit? Perhaps task cgroup >> membership changes and changes in available cgroups should be logged too? >> >> Some kind of cgroup IDs could be logged instead of long paths. Then >> these IDs should be reliably resolvable to paths offline somehow. > > I don't think that's doable. That pretty much requires the kernel to > remember paths of all past cgroups. That's a show stopper for audit approach for getting helpful information for configuration. I'll try something different, probably cgroupstats. -Topi > >> How usual migrations between cgroups are? Why would a task ever move >> from (say) systemd/system.slice/smartd.service to anywhere else? > > In most cases, they won't move once set up initially but that's not > the point of audit subsystem. Logging this once one exit isn't gonna > help anything for auditing the system. > > Thanks. >