Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp158167imp; Tue, 19 Feb 2019 20:43:32 -0800 (PST) X-Google-Smtp-Source: AHgI3IZgpFERAXXYPx1qsEhATh8T7AHgipcS8wRjgQ7Ewo6oF5fewX9I0/Zx6hShtDYmU/YnORZ5 X-Received: by 2002:a65:60c2:: with SMTP id r2mr27761702pgv.319.1550637812323; Tue, 19 Feb 2019 20:43:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550637812; cv=none; d=google.com; s=arc-20160816; b=CQFv6qGIgZwLU7CtXLYptxaWIvwOro3ZIZLoh3IC/irWEhrA2Iyy7C8xAerXajAahB mod080d7VXe+BvaIWXcXeqP2zTNsJ+pRKHtId0fmGjz/hw6PP8frxDkaTpEhDnXsNsGl TJlnXhK8PSOd2XHfxZmon1015Ju7VH54C7Ms0UwgaEEL9gBxCYl/3sqKYjq4k1JUy85i TrnBWnwRItm1K8BUwFiJC8CsXd1VMSGjD4TdnFBjcIVxctIqOzN4ujNGsulpsn1GAvOp kGHViJyVfLUR3vNYBB9oaluC4QEZe7rjtB8GYMJ+fGyZ/hrjjHyQqQKr1EwdzhrGhnfK EKEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:dkim-signature; bh=+5dvOBycnYMWuGZj6lOtHEPlsD1MLuFNwkZZ2UZcDGw=; b=FTeUOG1yO4ug37a2hDaiNJmhbWDXLW4nAjGikmpMlGqgp2r/JtWbxcVFGr63VoYPtc vdcBu0MjiwOEafUzZZXEvvmQZoJxFPxRFnQjmEee8KPIzl8y4Rz8eeFMT2IkIub+VW2Q E+MT2rWAPxrx5k7bVtOOeXHbgeUi1e0JdmY/WrYPF9VJygymApjdXJJ2PcNGRa4uB7Wu YKCpiLb5iw8ae2Okm4AQDgrj+dPth4+1tHau5bEhrOpvdKGToeSrRcoeZYI6zEI5E7sd Ztw0QfUdnNtKVbsbDqySqxhOSzYM8hGaD4d5izMk9/8CUvreXXZ7PAWrOMcex02qJqlF j3Eg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@themaw.net header.s=fm2 header.b=fJWHCeDO; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b="bbW61jV/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f34si18597019ple.279.2019.02.19.20.43.16; Tue, 19 Feb 2019 20:43:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@themaw.net header.s=fm2 header.b=fJWHCeDO; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b="bbW61jV/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730453AbfBTEmy (ORCPT + 99 others); Tue, 19 Feb 2019 23:42:54 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:54207 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726986AbfBTEmy (ORCPT ); Tue, 19 Feb 2019 23:42:54 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B3A4C2212C; Tue, 19 Feb 2019 23:42:52 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 19 Feb 2019 23:42:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s=fm2; bh= +5dvOBycnYMWuGZj6lOtHEPlsD1MLuFNwkZZ2UZcDGw=; b=fJWHCeDOWJrB9d4b iQS6dWvTeNrvNVeL2v0xBmihJLVqJsZsrhvLo6XN6PMo8Evb3im/zikl/E7Zg1rb VQYToPokZnDk5DQn1frkaSDk/ReS5QUeWlWYnGXVSsQ/OGx7haV2wpKPRtZRnWtW C1nYsGtyRScX+Mzlcp1ybQJlsSZqF7DFap5p/L8VEDDXcx99tqSmeXVD1wjbbQ5C vG1Zi8kWwmTgxcTGimK0wMXv017MuiChymz/rOKkrh1jYHPR1ieQSMPkBfbspwxK xXWl4w5wOAG7SH/hv+yVL1ZNrwgXVFuPseiC5z51BPXjYxS0UajMpfqIf4PaBcJG C89uDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=+5dvOBycnYMWuGZj6lOtHEPlsD1MLuFNwkZZ2UZcD Gw=; b=bbW61jV/iwi5m//ywRL+OjAd3wt+EUip16xooYsM1fmdfSedUn+4UUKut GD2h9YQynC7mPbmqfsYLG9/wecn5bfNzc5ma4tpesWe7V3d/vKBPlHdQLXI+xDrZ xURlUj2XrfKr/QbZQ+pojzfiNAgWroNjTfDneK4lYwv0GWXaq0/lo8VCA+rIoh54 /FZ+f5Hxq1Utgq0dFLVy3LxBXhXYvQPdXTVm7oQ5KcN2Ic0+SNux8ltXpfG6RqG2 MxUdzz1JvKHhr90swWKm1MYWsuqt8Qx/3HvlA0s2XVercy2/jskJ6a1/4jlDd6qQ LLs0F36dWNrwWCf0EijHflZmJ0vKw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrtdehgdejieculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkffuhffvffgjfhgtofgggfesthejredtredtjeenucfhrhhomhepkfgrnhcu mfgvnhhtuceorhgrvhgvnhesthhhvghmrgifrdhnvghtqeenucfkphepuddukedrvddtke drheehrdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehrrghvvghnsehthhgvmhgrfidr nhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost (unknown [118.208.55.8]) by mail.messagingengine.com (Postfix) with ESMTPA id 21E5510319; Tue, 19 Feb 2019 23:42:45 -0500 (EST) Message-ID: Subject: Re: [RFC PATCH 02/27] containers: Implement containers as kernel objects From: Ian Kent To: James Bottomley , David Howells Cc: keyrings@vger.kernel.org, trond.myklebust@hammerspace.com, sfrench@samba.org, linux-security-module@vger.kernel.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, linux-fsdevel@vger.kernel.org, rgb@redhat.com, linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, cgroups@vger.kernel.org Date: Wed, 20 Feb 2019 12:42:42 +0800 In-Reply-To: <1550634367.11684.6.camel@HansenPartnership.com> References: <1550432358.2809.21.camel@HansenPartnership.com> <155024683432.21651.14153938339749694146.stgit@warthog.procyon.org.uk> <155024685321.21651.1504201877881622756.stgit@warthog.procyon.org.uk> <19562.1550617574@warthog.procyon.org.uk> <1550629220.11684.3.camel@HansenPartnership.com> <054c1e762d28306abd4db9c42fb1c5f4261332fd.camel@themaw.net> <1550634367.11684.6.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-2.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2019-02-19 at 19:46 -0800, James Bottomley wrote: > On Wed, 2019-02-20 at 11:04 +0800, Ian Kent wrote: > > On Tue, 2019-02-19 at 18:20 -0800, James Bottomley wrote: > > > On Tue, 2019-02-19 at 23:06 +0000, David Howells wrote: > > > > James Bottomley wrote: > > > > > > > > > I thought we got agreement years ago that containers don't > > > > > exist in Linux as a single entity: they're currently a > > > > > collection of cgroups and namespaces some of which may and some > > > > > of which may not be local to the entity the orchestration > > > > > system thinks of as a "container". > > > > > > > > I wasn't party to that agreement and don't feel particularly > > > > bound by it. > > > > > > That's not at all relevant, is it? The point is we have widespread > > > uses of namespaces and cgroups that span containers today meaning > > > that a "container id" becomes a problematic concept. What we > > > finally got to with the audit people was an unmodifiable label > > > which the orchestration system can set ... can't you just use that? > > > > Sorry James, I fail to see how assigning an id to a collection of > > objects constitutes a problem or how that could restrict the way a > > container is used. > > Rather than rehash the whole argument again, what's the reason you > can't use the audit label? It seems to do what you want in a way that > doesn't cause problems. If you can just use it there's little point > arguing over what is effectively a moot issue. David might want to use the audit label for this, I don't know. And maybe that's a good choice initially. But going way off topic. Because there is a need to not clutter kernel space with logging, leaving it to user space to handle but also without providing user space with sufficient information to do so there will need to be some sort of globally unique (sub-system) identifiers of kernel objects for which user space needs logging information so that if or when that kernel to user space information flow is implemented the consistent identifiers that will be needed will at least exist for some kernel objects. Yes, that's way off topic for this series but I think it's something that needs at least some consideration for new implementation work. Unfortunately properly implementing such an encoding scheme probably warrants a completely separate project so, as you say moot wrt. this series. > > James > > > > Isn't the only problem here the current restrictions on the way > > objects need to be combined as a set and the ability to be able add > > or subtract from that set. > > > > Then again the notion of active vs. inactive might not be sufficient > > to allow for the needed flexibility ... > > > > Ian > > > >