From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Filip Schauer <f.schauer@proxmox.com>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [PATCH container 7/8] implement per-mountpoint uid/gid mapping
Date: Tue, 3 Mar 2026 17:16:03 +0100 [thread overview]
Message-ID: <3sazssdxkf3n42ngymn6ofht5mqsx5uemy2qvqfsxre3npjisp@juc3tsramsc3> (raw)
In-Reply-To: <e8e9fab5-0566-47d9-999b-bf77a4d36dad@proxmox.com>
On Tue, Mar 03, 2026 at 02:59:11PM +0100, Filip Schauer wrote:
> On 27/02/2026 16:33, Wolfgang Bumiller wrote:
> > The pre-start hook gets a `$namespaces` hash passed as 3rd
> > parameter, we can just open the user namespace fd there for this
> > purpose.
>
> I just realized that this won't work. The pre-start hook cannot access
> the container's user namespace, since the container's init process
> wasn't even started yet.
We could see if a `start-host` hook applying the idmapping after the
fact could do the job, but I'm not a big fan of splitting the mounting
into phases like this.
>
> We could however still reuse the container namespace when hot-plugging.
Yeah, if we want to special case this.
Other than that, we could at least cache the namespaces somewhere via
bind mounts so we can reuse them in hotplugging, too, but that can be
added as a follow up as well, since that's rather the exception, not the
rule. For the regular setup code, simply caching the fds in a hash is
enough.
next prev parent reply other threads:[~2026-03-03 16:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 13:04 [PATCH common/container/manager 0/8] " Filip Schauer
2026-02-23 13:04 ` [PATCH common 1/8] tools: export O_CLOEXEC constant Filip Schauer
2026-02-23 13:04 ` [PATCH common 2/8] syscall: add missing mount attribute constants Filip Schauer
2026-02-23 13:04 ` [PATCH common 3/8] tools: add mount_setattr syscall Filip Schauer
2026-02-23 13:04 ` [PATCH container 4/8] namespaces: relax prototype of run_in_userns Filip Schauer
2026-02-23 13:04 ` [PATCH container 5/8] namespaces: refactor run_in_userns Filip Schauer
2026-02-23 13:04 ` [PATCH container 6/8] namespaces: add helper to create user namespace from idmap Filip Schauer
2026-02-23 13:04 ` [PATCH container 7/8] implement per-mountpoint uid/gid mapping Filip Schauer
2026-02-27 14:39 ` Maximiliano Sandoval
2026-02-27 15:01 ` Daniel Kral
2026-02-27 15:34 ` Wolfgang Bumiller
2026-03-02 16:37 ` Filip Schauer
2026-03-02 18:05 ` Filip Schauer
2026-03-03 11:52 ` Wolfgang Bumiller
2026-03-03 13:59 ` Filip Schauer
2026-03-03 16:16 ` Wolfgang Bumiller [this message]
2026-02-23 13:04 ` [PATCH manager 8/8] ui: lxc/MPEdit: add "idmap" option Filip Schauer
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=3sazssdxkf3n42ngymn6ofht5mqsx5uemy2qvqfsxre3npjisp@juc3tsramsc3 \
--to=w.bumiller@proxmox.com \
--cc=f.schauer@proxmox.com \
--cc=pve-devel@lists.proxmox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox