Re: [PATCH v3] feat: Add cli option '--pass-fds' for pasta mode.

[Stefano Brivio <sbrivio@redhat.com>]

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" <rlawrence@tamu.edu> 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).

> In the end, I felt super, super frustrated because what seemed like an easy problem turned out to be nearly impossible. In my workplace, I am considered the local expert on containers, and even I couldn't figure it out. My LLM coding agent couldn't figure it out either. This would be completely hopeless for some gamer trying to isolate network access for a multiplayer game installed via flatpak.
> 
> I teach the container shortcourse at my institution, and I genuinely care about the future of this technology. It is my hope to help make modern lightweight and secure container technologies as user-friendly as possible, so that more people will choose them over "sudo docker".

Thanks for that as well, it's definitely a goal of mine too.

> If we can reach a consensus regarding the ideal scope of this feature, I will gladly address all your technical complaints.

By the way I think there's consensus, the only issue David was raising
here is that the motivation wasn't sufficiently explained or
documented.

It wasn't clear for me either, judging from issue #204 alone, why
bubblewrap couldn't do that. It looks like it could, but it's not
implemented.

> [...]

-- 
Stefano