[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reviving schroot as used by sbuild





On Mon, Jul 1, 2024 at 11:59 AM Simon McVittie <smcv@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.

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

Reply to: