From: Ian Kent <raven@themaw.net> To: James Bottomley <James.Bottomley@HansenPartnership.com>, David Howells <dhowells@redhat.com> 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 Subject: Re: [RFC PATCH 02/27] containers: Implement containers as kernel objects Date: Wed, 20 Feb 2019 04:42:42 +0000 [thread overview] Message-ID: <e41d7a4e072ac33774090b6a5aff6d3a45445a36.camel@themaw.net> (raw) In-Reply-To: <1550634367.11684.6.camel@HansenPartnership.com> 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 <James.Bottomley@HansenPartnership.com> 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 > > > >
WARNING: multiple messages have this Message-ID (diff)
From: Ian Kent <raven@themaw.net> To: James Bottomley <James.Bottomley@HansenPartnership.com>, David Howells <dhowells@redhat.com> 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 Subject: Re: [RFC PATCH 02/27] containers: Implement containers as kernel objects Date: Wed, 20 Feb 2019 12:42:42 +0800 [thread overview] Message-ID: <e41d7a4e072ac33774090b6a5aff6d3a45445a36.camel@themaw.net> (raw) In-Reply-To: <1550634367.11684.6.camel@HansenPartnership.com> 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 <James.Bottomley@HansenPartnership.com> 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 > > > >
next prev parent reply other threads:[~2019-02-20 4:42 UTC|newest] Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-15 16:07 [RFC PATCH 00/27] Containers and using authenticated filesystems David Howells 2019-02-15 16:07 ` David Howells 2019-02-15 16:07 ` [RFC PATCH 01/27] containers: Rename linux/container.h to linux/container_dev.h David Howells 2019-02-15 16:07 ` [RFC PATCH 02/27] containers: Implement containers as kernel objects David Howells 2019-02-15 16:07 ` David Howells 2019-02-17 18:57 ` Trond Myklebust 2019-02-17 18:57 ` Trond Myklebust 2019-02-17 19:39 ` James Bottomley 2019-02-17 19:39 ` James Bottomley 2019-02-19 16:56 ` Eric W. Biederman 2019-02-19 16:56 ` Eric W. Biederman 2019-02-19 23:03 ` David Howells 2019-02-19 23:03 ` David Howells 2019-02-20 14:23 ` Trond Myklebust 2019-02-20 14:23 ` Trond Myklebust 2019-02-19 23:06 ` David Howells 2019-02-20 2:20 ` James Bottomley 2019-02-20 2:20 ` James Bottomley 2019-02-20 3:04 ` Ian Kent 2019-02-20 3:04 ` Ian Kent 2019-02-20 3:46 ` James Bottomley 2019-02-20 3:46 ` James Bottomley 2019-02-20 4:42 ` Ian Kent [this message] 2019-02-20 4:42 ` Ian Kent 2019-02-20 6:57 ` Paul Moore 2019-02-20 6:57 ` Paul Moore 2019-02-19 23:13 ` David Howells 2019-02-19 23:13 ` David Howells 2019-02-19 23:55 ` Tycho Andersen 2019-02-19 23:55 ` Tycho Andersen 2019-02-20 2:46 ` Ian Kent 2019-02-20 2:46 ` Ian Kent 2019-02-20 13:26 ` Christian Brauner 2019-02-20 13:26 ` Christian Brauner 2019-02-20 13:26 ` Christian Brauner 2019-02-21 10:39 ` Ian Kent 2019-02-21 10:39 ` Ian Kent 2019-02-15 16:07 ` [RFC PATCH 03/27] containers: Provide /proc/containers David Howells 2019-02-15 16:07 ` David Howells 2019-02-15 16:07 ` [RFC PATCH 04/27] containers: Allow a process to be forked into a container David Howells 2019-02-15 17:39 ` Stephen Smalley 2019-02-15 17:39 ` Stephen Smalley 2019-02-19 16:39 ` Eric W. Biederman 2019-02-19 16:39 ` Eric W. Biederman 2019-02-19 23:16 ` David Howells 2019-02-19 23:16 ` David Howells 2019-02-15 16:07 ` [RFC PATCH 05/27] containers: Open a socket inside " David Howells 2019-02-19 16:41 ` Eric W. Biederman 2019-02-19 16:41 ` Eric W. Biederman 2019-02-15 16:08 ` [RFC PATCH 06/27] containers, vfs: Allow syscall dirfd arguments to take a container fd David Howells 2019-02-19 16:45 ` Eric W. Biederman 2019-02-19 16:45 ` Eric W. Biederman 2019-02-19 23:24 ` David Howells 2019-02-19 23:24 ` David Howells 2019-02-15 16:08 ` [RFC PATCH 07/27] containers: Make fsopen() able to create a superblock in a container David Howells 2019-02-15 16:08 ` David Howells 2019-02-15 16:08 ` [RFC PATCH 08/27] containers, vfs: Honour CONTAINER_NEW_EMPTY_FS_NS David Howells 2019-02-17 0:11 ` Al Viro 2019-02-15 16:08 ` [RFC PATCH 09/27] vfs: Allow mounting to other namespaces David Howells 2019-02-17 0:14 ` Al Viro 2019-02-15 16:08 ` [RFC PATCH 10/27] containers: Provide fs_context op for container setting David Howells 2019-02-15 16:09 ` [RFC PATCH 11/27] containers: Sample program for driving container objects David Howells 2019-02-15 16:09 ` David Howells 2019-02-15 16:09 ` [RFC PATCH 12/27] containers: Allow a daemon to intercept request_key upcalls in a container David Howells 2019-02-15 16:09 ` David Howells 2019-02-15 16:09 ` [RFC PATCH 13/27] keys: Provide a keyctl to query a request_key authentication key David Howells 2019-02-15 16:09 ` [RFC PATCH 14/27] keys: Break bits out of key_unlink() David Howells 2019-02-15 16:09 ` David Howells 2019-02-15 16:09 ` [RFC PATCH 15/27] keys: Make __key_link_begin() handle lockdep nesting David Howells 2019-02-15 16:09 ` David Howells 2019-02-15 16:09 ` [RFC PATCH 16/27] keys: Grant Link permission to possessers of request_key auth keys David Howells 2019-02-15 16:10 ` [RFC PATCH 17/27] keys: Add a keyctl to move a key between keyrings David Howells 2019-02-15 16:10 ` David Howells 2019-02-15 16:10 ` [RFC PATCH 18/27] keys: Find the least-recently used unseen key in a keyring David Howells 2019-02-15 16:10 ` David Howells 2019-02-15 16:10 ` [RFC PATCH 19/27] containers: Sample: request_key upcall handling David Howells 2019-02-15 16:10 ` David Howells 2019-02-15 16:10 ` [RFC PATCH 20/27] container, keys: Add a container keyring David Howells 2019-02-15 16:10 ` David Howells 2019-02-15 21:46 ` Eric Biggers 2019-02-15 21:46 ` Eric Biggers 2019-02-15 16:11 ` [RFC PATCH 21/27] keys: Fix request_key() lack of Link perm check on found key David Howells 2019-02-15 16:11 ` [RFC PATCH 22/27] KEYS: Replace uid/gid/perm permissions checking with an ACL David Howells 2019-02-15 16:11 ` David Howells 2019-02-15 17:32 ` Stephen Smalley 2019-02-15 17:32 ` Stephen Smalley 2019-02-15 17:39 ` David Howells 2019-02-15 17:39 ` David Howells 2019-09-30 16:39 ` Richard Haines 2019-09-30 16:39 ` Richard Haines 2019-02-15 16:11 ` [RFC PATCH 23/27] KEYS: Provide KEYCTL_GRANT_PERMISSION David Howells 2019-02-15 16:11 ` David Howells 2019-02-15 16:11 ` [RFC PATCH 24/27] keys: Allow a container to be specified as a subject in a key's ACL David Howells 2019-02-15 16:11 ` David Howells 2019-02-15 16:11 ` [RFC PATCH 25/27] keys: Provide a way to ask for the container keyring David Howells 2019-02-15 16:11 ` David Howells 2019-02-15 16:12 ` [RFC PATCH 26/27] keys: Allow containers to be included in key ACLs by name David Howells 2019-02-15 16:12 ` David Howells 2019-02-15 16:12 ` [RFC PATCH 27/27] containers: Sample to grant access to a key in a container David Howells 2019-02-15 16:12 ` David Howells 2019-02-15 22:36 ` [RFC PATCH 00/27] Containers and using authenticated filesystems James Morris 2019-02-15 22:36 ` James Morris 2019-02-19 16:35 ` Eric W. Biederman 2019-02-19 16:35 ` Eric W. Biederman 2019-02-19 16:35 ` Eric W. Biederman 2019-02-20 14:18 ` Christian Brauner 2019-02-20 14:18 ` Christian Brauner 2019-02-19 23:42 ` David Howells 2019-02-19 23:42 ` David Howells 2019-02-20 7:00 ` Paul Moore 2019-02-20 7:00 ` Paul Moore 2019-02-20 18:54 ` Steve French 2019-02-20 18:54 ` Steve French
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=e41d7a4e072ac33774090b6a5aff6d3a45445a36.camel@themaw.net \ --to=raven@themaw.net \ --cc=James.Bottomley@HansenPartnership.com \ --cc=cgroups@vger.kernel.org \ --cc=containers@lists.linux-foundation.org \ --cc=dhowells@redhat.com \ --cc=keyrings@vger.kernel.org \ --cc=linux-cifs@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nfs@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=rgb@redhat.com \ --cc=sfrench@samba.org \ --cc=trond.myklebust@hammerspace.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.