From: Christian Brauner <email@example.com> To: Giuseppe Scrivano <firstname.lastname@example.org> Cc: email@example.com, "Serge E. Hallyn" <firstname.lastname@example.org>, email@example.com Subject: Re: [PATCH v2] userns: automatically split user namespace extent Date: Mon, 7 Jun 2021 13:08:04 +0200 [thread overview] Message-ID: <20210607110804.qgkpxktig2upzfrk@wittgenstein> (raw) In-Reply-To: <firstname.lastname@example.org> On Mon, Jun 07, 2021 at 11:31:37AM +0200, Giuseppe Scrivano wrote: > Christian Brauner <email@example.com> writes: > > > On Fri, Jun 04, 2021 at 04:41:19PM +0200, Giuseppe Scrivano wrote: > >> Christian, Eric, > >> > >> are you fine with this patch or is there anything more you'd like me to > >> change? > > > > Before being a little bit of a party pooper thanks for your patches! I > > appreciate the work you're doing! > > > > So my concern is that this may cause silent regressions/security issues > > for tools in userspace by making this work automagically. > > > > For example we have a go library that calculates idmap ranges and > > extents. Those idmappings are stored in the database and in the > > container's config and for backups and so on. > > > > The calculated extents match exactly with how these lines look in > > /proc/<pid>/*id_map. > > If we miscalculate the extents and we try to write them to > > /proc/<pid>/*id_map we get told to go away and immediately recognize the > > bug. > > With this patch however we may succeed and then we record misleading > > extents in the db or the config. > > > > Turning this into a general concern, I think it is a non-trivial > > semantic change to break up the 1:1 correspondence between mappings > > written and mappings applied that we had for such a long time now. > > > > In general I'm not sure it should be the kernel that has the idmapping > > ranges smarts. > > > > I'd rather see a generic userspace library that container runtimes make > > use of that also breaks up idmapping ranges. We can certainly accomodate > > this in > > https://pkg.go.dev/github.com/lxc/lxd/shared/idmap > > > > Is that a reasonable concern? > > I've ended up adding a similar logic to Podman for the same reason as > above. > > In our use case, containers are created within a user namespace that > usually has two extents, the current unprivileged ID mapped to root, > and any additional ID allocated to the user through /etc/sub?id mapped > to 1. > > Within this user namespace, other user namespaces can be created and we > let users specify the mappings. It is a common mistake to specify a > mapping that overlaps multiple extents in the parent userns e.g: > 0:0:IDS_AVAILABLE. > > To avoid the problem we have to first parse /proc/self/?id_map and then > split the specified extents when they overlap. > > In our case this is not an issue anymore, moving the logic to the kernel > would just avoid a open syscall. > > IMHO the 1:1 mapping is just an implementation detail, that is not With proc such details tend to have the unfortunate tendency to become part of the api which is what makes me a bit uneasy. For non-lxd users that use the low-level lxc library directly we allow callers to specify the idmappings in the exact same format they will appear in procfs. This means you can reason 1:1 about the extents used. A change like this on the kernel level would break that assumption meaning e.g. that container configs would suddenly start that would otherwise fail because of miscalculated or "wrong" extents. Since we all have solved that problem in userspace already saving a single open system call is not a good enough win maybe. It feels like the new libsubid library in shadow that we added should grow that feature to split extents instead. Potentially making new*idmap handle that case by default in newer versions. That's easier to revert if anything breaks, allows us to see whether this causes trouble, and users that write to new*idmap directly aren't affected at all. Christian
prev parent reply other threads:[~2021-06-07 11:08 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-03 15:02 Giuseppe Scrivano 2021-05-10 17:23 ` Serge E. Hallyn 2021-05-10 18:57 ` Serge E. Hallyn 2021-06-04 14:41 ` Giuseppe Scrivano 2021-06-05 13:00 ` Christian Brauner 2021-06-07 9:31 ` Giuseppe Scrivano 2021-06-07 11:08 ` Christian Brauner [this message]
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=20210607110804.qgkpxktig2upzfrk@wittgenstein \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2] userns: automatically split user namespace extent' \ /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
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.