From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Jarkko Sakkinen" <jarkko@kernel.org>,
"Casey Schaufler" <casey@schaufler-ca.com>,
"Jonathan Calmels" <jcalmels@3xx0.net>, <brauner@kernel.org>,
<ebiederm@xmission.com>, "Luis Chamberlain" <mcgrof@kernel.org>,
"Kees Cook" <keescook@chromium.org>,
"Joel Granados" <j.granados@samsung.com>,
"Serge Hallyn" <serge@hallyn.com>,
"Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"David Howells" <dhowells@redhat.com>
Cc: <containers@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<linux-fsdevel@vger.kernel.org>,
<linux-security-module@vger.kernel.org>,
<keyrings@vger.kernel.org>
Subject: Re: [PATCH 0/3] Introduce user namespace capabilities
Date: Thu, 16 May 2024 23:00:25 +0300 [thread overview]
Message-ID: <D1BC3VWXKTNC.2DB9JIIDOFIOQ@kernel.org> (raw)
In-Reply-To: <D1BBI1LX2FMW.3MTQAHW0MA1IH@kernel.org>
On Thu May 16, 2024 at 10:31 PM EEST, Jarkko Sakkinen wrote:
> On Thu May 16, 2024 at 10:29 PM EEST, Jarkko Sakkinen wrote:
> > On Thu May 16, 2024 at 10:07 PM EEST, Casey Schaufler wrote:
> > > I suggest that adding a capability set for user namespaces is a bad idea:
> > > - It is in no way obvious what problem it solves
> > > - It is not obvious how it solves any problem
> > > - The capability mechanism has not been popular, and relying on a
> > > community (e.g. container developers) to embrace it based on this
> > > enhancement is a recipe for failure
> > > - Capabilities are already more complicated than modern developers
> > > want to deal with. Adding another, special purpose set, is going
> > > to make them even more difficult to use.
> >
> > What Inh, Prm, Eff, Bnd and Amb is not dead obvious to you? ;-)
> > One UNs cannot hurt...
> >
> > I'm not following containers that much but didn't seccomp profiles
> > supposed to be the silver bullet?
>
> Also, I think Kata Containers style way of doing containers is pretty
> solid. I've heard that some video streaming service at least in recent
> past did launch VM per stream so it's not like VM's cannot be made to
> scale I guess.
Sorry for multiple responses but this actually nails the key question:
who will use this? Even if this would work out somehow, is there someone
who will actually use this, and not few other more robust solutions
available? I mean it is worth of time to maintain it, if there is no
potential users for a feature.
In addition to "show me the code", there is always also "show me the payload".
BR, Jarkko
next prev parent reply other threads:[~2024-05-16 20:00 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 9:22 [PATCH 0/3] Introduce user namespace capabilities Jonathan Calmels
2024-05-16 9:22 ` [PATCH 1/3] capabilities: " Jonathan Calmels
2024-05-16 12:27 ` Jarkko Sakkinen
2024-05-16 22:07 ` John Johansen
2024-05-17 10:51 ` Jonathan Calmels
2024-05-17 11:59 ` John Johansen
2024-05-18 3:50 ` Jonathan Calmels
2024-05-18 12:27 ` John Johansen
2024-05-19 1:33 ` Jonathan Calmels
2024-05-17 11:32 ` Eric W. Biederman
2024-05-17 11:55 ` Jonathan Calmels
2024-05-17 12:48 ` John Johansen
2024-05-17 14:22 ` Eric W. Biederman
2024-05-17 18:02 ` Jonathan Calmels
2024-05-21 15:52 ` John Johansen
2024-05-20 3:30 ` Serge E. Hallyn
2024-05-20 3:36 ` Serge E. Hallyn
2024-05-16 9:22 ` [PATCH 2/3] capabilities: add securebit for strict userns caps Jonathan Calmels
2024-05-16 12:42 ` Jarkko Sakkinen
2024-05-20 3:38 ` Serge E. Hallyn
2024-05-16 9:22 ` [PATCH 3/3] capabilities: add cap userns sysctl mask Jonathan Calmels
2024-05-16 12:44 ` Jarkko Sakkinen
2024-05-20 3:38 ` Serge E. Hallyn
2024-05-20 13:30 ` Tycho Andersen
2024-05-20 19:25 ` Jonathan Calmels
2024-05-20 21:13 ` Tycho Andersen
2024-05-20 22:12 ` Jarkko Sakkinen
2024-05-21 14:29 ` Tycho Andersen
2024-05-21 14:45 ` Jarkko Sakkinen
2024-05-16 13:30 ` [PATCH 0/3] Introduce user namespace capabilities Ben Boeckel
2024-05-16 13:36 ` Jarkko Sakkinen
2024-05-17 10:00 ` Jonathan Calmels
2024-05-16 16:23 ` Paul Moore
2024-05-16 17:18 ` Jarkko Sakkinen
2024-05-16 19:07 ` Casey Schaufler
2024-05-16 19:29 ` Jarkko Sakkinen
2024-05-16 19:31 ` Jarkko Sakkinen
2024-05-16 20:00 ` Jarkko Sakkinen [this message]
2024-05-17 11:42 ` Jonathan Calmels
2024-05-17 17:53 ` Casey Schaufler
2024-05-17 19:11 ` Jonathan Calmels
2024-05-18 11:08 ` Jarkko Sakkinen
2024-05-18 11:17 ` Jarkko Sakkinen
2024-05-18 11:21 ` Jarkko Sakkinen
2024-05-21 13:57 ` John Johansen
2024-05-21 14:12 ` Jarkko Sakkinen
2024-05-21 14:45 ` John Johansen
2024-05-22 0:45 ` Jonathan Calmels
2024-05-31 7:43 ` John Johansen
2024-05-18 12:20 ` Serge Hallyn
2024-05-19 17:03 ` Casey Schaufler
2024-05-20 0:54 ` Jonathan Calmels
2024-05-21 14:29 ` John Johansen
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=D1BC3VWXKTNC.2DB9JIIDOFIOQ@kernel.org \
--to=jarkko@kernel.org \
--cc=brauner@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=containers@lists.linux.dev \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=j.granados@samsung.com \
--cc=jcalmels@3xx0.net \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.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: link
Be 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.