Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946035AbbEOUmu (ORCPT ); Fri, 15 May 2015 16:42:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36916 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161015AbbEOUmq (ORCPT ); Fri, 15 May 2015 16:42:46 -0400 From: Paul Moore To: Oren Laadan Cc: Richard Guy Briggs , Steve Grubb , linux-api@vger.kernel.org, Linux Containers , linux-kernel , viro@zeniv.linux.org.uk, linux-audit@redhat.com, netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, eparis@parisplace.org, zohar@linux.vnet.ibm.com, Eric Biederman Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances Date: Fri, 15 May 2015 16:42:38 -0400 Message-ID: <2697338.ReFgH43Z0x@sifl> Organization: Red Hat User-Agent: KMail/4.14.6 (Linux/3.16.7-gentoo; KDE/4.14.7; x86_64; ; ) In-Reply-To: References: <20150515004855.GB10526@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1694 Lines: 35 On Thursday, May 14, 2015 09:10:56 PM Oren Laadan wrote: > [focusing on "containers id" - snipped the rest away] > > I am unfamiliar with the audit subsystem, but work with namespaces in other > contexts. Perhaps the term "container" is overloaded here. The definition > suggested by Steve in this thread makes sense to me: "a combination of > namespaces". I imagine people may want to audit subsets of namespaces. > > For namespaces, can use a string like "A:B:C:D:E:F" as an identifier for a > particular combination, where A-F are respective namespaces identifiers. > (Can be taken for example from /proc/PID/ns/{mnt,uts,ipc,user,pid,net}). > That will even be grep-able to locate records related to a particular > subset > of namespaces. So a "container" in the classic meaning would have all A-F > unique and different from the init process, but processes separated only by > e.g. mnt-ns and net-ns will differ from the init process in A and F. > > (If a string is a no go, then perhaps combine the IDs in a unique way into a > super ID). As has been mentioned in every other email in this thread, the kernel has no concept of a container, it is a userspace idea and trying to generate a meaningful value in the kernel is a mistake in my opinion. My current opinion is that we allow userspace to set a container ID token as it sees fit and the kernel will just use the value provided by userspace. -- paul moore security @ redhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/