On Wed, Jul 22, 2026 at 12:45:25AM +0200, Stefano Brivio wrote:
Richard, I haven't found the time to review your patch in detail yet and the whole problem description, just a few notes so far:
On Tue, 21 Jul 2026 04:44:05 +0000 "Lawrence, Richard E"
wrote: [...]
I tried executing bubblewrap within pasta. And it's so close to being what I wanted! It's a simple one-liner and for some reason I don't understand, avoids the issue with the nested namespace. But it still isn't what I wanted, because another thing I like to do is deliver bwrap's many many args to it via a file descriptor (--args FD) to simplify the process name for ps and avoid leaking private information to anyone else running on the same node. But since pasta couldn't pass FD's through to bubblewrap, so now I have to wrap my bubblewrap command inside some other bespoke script whose job is to open a temporary file I am serving somewhere, which just becomes another opportunity to leak my private information.
By the way, you don't seem to be the only one using a workaround like this, see also:
https://github.com/reubenfirmin/bubblewrap-tui#why-pasta
Sidebar: if you think about it, the only reason the nsenter strategy can even be considered a "workaround" for pasta not having --pass-fd is that nsenter does have the feature to pass FD's through (in fact, it is the default). That's not a good look for pasta.
Sidebar: Yes, it can be said that my problem would be solved on the bubblewrap side if only bubblewrap could join an existing network namespace. I also submitted the PR to create that feature.
Ah, interesting, thanks for doing that. That should hopefully solve this specific problem. At the same time:
Nevertheless, I feel strongly that passing FD's has other plausible consumers besides specifically bubblewrap.
...this sounds quite likely as well, given it's already two people including you requesting this feature, and the other example of a workaround, even though it's a workaround for what I consider a missing feature in bubblewrap, because it should really have a proper integration (just like Podman, Docker / rootlesskit, libvirt, libkrun, etc. have). See also:
https://bugs.passt.top/show_bug.cgi?id=214
for another consequence of a missing integration.
But given the likelihood of that, I'm also rather convinced that this option might be useful for this case or for other cases.
I just think that we should implement it in the simplest possible way, and if spawning the command before closing file descriptors (which would remain open in the child process only) works as well, I would suggest to go for that (sorry it didn't occur to me as I had a look at v1).
Right. Note that as well as being (I think) a simpler implementation, that will be a better UX: you don't need to enumerate all the fds and add an option for them. Plus I think it makes more logical sense - our self-isolation steps are to isolate, well, ourselves. They're not really intended for the spawned commaned. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson