Richard,
On Fri, 14 Aug 2026 18:12:56 +0000
"Lawrence, Richard E"
Howdy Stefano, David,
I don't understand the plan. Are you waiting on me? Am I waiting on you?
I could implement any of these ideas, but I don't wish to implement **all** of them. Can we reach a consensus?
Sorry for the extremely long delay here. I think at this point there are no moving parts in isolation.c and surroundings, and we could go back to one of those ideas. None of the reworks that occurred meanwhile would seem to make ideas based on partial close_ranges() or reading out procfs entries (as your v2 does) any easier. My two proposals (wrapper around open() maintaining an array of files we shouldn't close, or having all open files in a specific struct / array can check easily) weren't made any easier either. At this point I would be inclined to suggest something like your ealier v3 adding a specific configuration option. To somewhat retain as much as possible of the original security benefits, we could explicitly limit that to the case where pasta(1) spawns another command, because the only use case where we have any evidence of this need is starting Bubblewrap from pasta's command line. I'm sorry this wait hasn't been particularly productive but at some point it looked like we could introduce a easy way to defer closing files so that the command spawned by pasta could simply inherit them unconditionally. That doesn't seem to be the case though. Let me know if you need any help in reviving your earlier v3, or if you need any support with anything related. -- Stefano