On Mon, Jul 1, 2024 at 11:59 AM Simon McVittie <s...@debian.org> wrote:
> On Mon, 01 Jul 2024 at 09:18:19 +0200, Philipp Kern wrote:
> One use-case that I'm familiar with is bwrap (bubblewrap, as used by
> flatpak) nested inside podman. bwrap is a relatively limited container
> technology with relatively "light" requirements, at the cost of imposing
> harsh restrictions on the code inside the container: you only get access
> to one uid, and all other uids get mapped to the overflow uid ("nobody).
> You can think of as having two possible identities, "me" and "not me".
> Even with that limitation, bwrap inside podman doesn't normally work,
> because podman forbids most nested container operations. I'm unsure
> whether this is a functional requirement to prevent attacks where the
> podman container "payload" escapes from the container and gets arbitrary
> code execution on the host, or whether this is merely non-essential
> security hardening to make it harder to exploit possible vulnerabilities
> that podman aims to already prevent in some other way. Either way,
> I would expect that buildd operators would not want to allow it.
>
> podman nested inside podman is "more difficult" than bwrap nested inside
> podman (because it's more capable and imposes fewer restrictions on the
> payload, therefore needs a larger-than-default block of uids to be made
> available, whereas bwrap only needs one uid), and almost certainly also
> won't work.
>
you might find https://www.redhat.com/sysadmin/podman-inside-container
an interesting and useful read on this topic.
tl;dr: it depends. When discussing nesting containers with
podman, specifically podman-in-podman, there are four cases to consider:
- Rootful Podman in rootful Podman
- Rootless Podman in rootful Podman
- Rootful Podman in rootless Podman
- Rootless Podman in rootless Podman
Those cases naturally translate when considering other technologies such as
bubblewrap or unshare.
best,
Reinhard
