On Tue, Sep 08, 2026 at 05:32:34PM +0200, Stefano Brivio wrote: > On Tue, 8 Sep 2026 21:09:36 +1000 > David Gibson wrote: > > > On Tue, Sep 08, 2026 at 11:45:07AM +0200, Stefano Brivio wrote: > > > On Tue, 8 Sep 2026 16:03:07 +1000 > > > David Gibson wrote: > > > > > > > On Sun, Sep 06, 2026 at 03:17:58PM +0200, Christian Korneck wrote: > > > > > This is to allow running pasta inside a container without unmasking > > > > > /proc for the whole container (Docker's --security-opt > > > > > systempaths=unconfined, Podman's --security-opt unmask=ALL), which is > > > > > undesirable as it exposes /proc/sysrq-trigger and other masked paths. > > > > > > > > > > In spawn mode, pasta clones the command with CLONE_NEWPID and mounts a > > > > > new procfs instance on /proc, so that it matches the new PID namespace. > > > > > > > > > > Mounting procfs in a new user namespace requires a fully visible, > > > > > unobstructed procfs. Container runtimes deliberately obstruct /proc > > > > > (Docker, for example, masks /proc/kcore and friends and mounts > > > > > /proc/sys read-only), so the mount is refused: > > > > > > > > > > Couldn't mount /proc: Operation not permitted > > > > > > > > > > We only warn and continue, leaving the command in a new PID namespace > > > > > while the visible /proc still numbers processes in the outer one. > > > > > Anything resolving its own PID through /proc then fails, for example > > > > > bubblewrap: > > > > > > > > > > bwrap: open /proc/22/ns/ns failed: No such file or directory > > > > > > > > > > Add a --no-pidns option: skip CLONE_NEWPID for the spawned command and > > > > > don't mount /proc, which is then not needed. User, network, mount, UTS > > > > > and IPC namespaces, --config-net and port forwarding are unaffected. > > > > > The option is rejected together with PID or --netns, as it only makes > > > > > sense when we spawn the command ourselves. > > > > > > > > > > Add a test checking that, by default, the command runs in a new PID > > > > > namespace, and that --no-pidns keeps it in the caller's one. > > > > > > > > I can see that this would be useful. On the other hand, I could say > > > > that for just about any combinatiom of unshare(1) options, and I don't > > > > think we want to reimplement all of unshare(1) in pasta. > > > > > > Certainly we don't, but we don't get requests like these frequently > > > (except for the one to drop namespacing altogether, which is another > > > story), so I think it's acceptable. > > > > Fair point. > > > > > The patch looks also pretty good and complete, so really low effort from > > > my side. > > > > > > > Note that it > > > > is always possible to create a namespace using unshare(1) with > > > > arbitrary options and then connect it with pasta, rather than having > > > > pasta create its own. > > > > > > > > That said, I've never seen the point of creating a pidns by default in > > > > pasta. We're not isolating the filesystem, so I don't see that > > > > there's much to gain by isolating pids. I'd be happy enough to see > > > > CLONE_NEWPID removed unconditionally. > > > > > > The points are described in the message for 0515adceaa8f > > > ("passt, pasta: Namespace-based sandboxing, defer seccomp policy > > > application"): > > > > Sorry, to be clear, I absolutely see the point of CLONE_NEWPID for > > passt/pasta itself. It's specifically for the spawned shell/process > > that I don't see the benefit. > > Ah, yeah, in that case it's just about cleaning up. > > > > - no need to track child processes: when PID 1 exits, they all > > > terminate, instead of that crazy / buggy hack I implemented before > > > this change > > > > I guess. But is cleaning up the spawned process really pasta's job? > > Perhaps not (see below), but it's extremely convenient, especially if > one runs nested pasta or a bunch of commands in subshells as a > one-liner reproducer, which is the main usage of it for myself and > quite a few people judging from bug reports. Hm, ok. Do you often encounter programs that don't neatly clean themselves up? > Before 0515adceaa8f, I spent some substantial effort to make sure that > the previous hack would clean up as much as possible, because I used to > constantly end up with a pile of 'ping' processes, HTTP clients / > servers, iperf3 instances, tcpdump, etc. hanging around, and most > annoyingly bound to ports. I guess you must have. > So I find it very useful that it reliably cleans up after my debug / > development mess. Ok, makes sense. > > It's not, of itself, a container tool. > > It's probably not. However, myself and others find it useful as > "network container" tool, which doesn't have an exact definition, but > it's nice to have as a "run a test and clean up all the traces" thing. > > It's more than a "network namespace connector" tool in that sense. If > one needs just that, they'll probably use pasta without spawning a > command anyway, together with an actual container tool. > > > > - for passt, to avoid possible attacks based on the knowledge of a > > > target process' PID, but then I realised that would also apply to > > > pasta's spawned process > > > > Right, for passt itself this is certainly worthwhile. If nothing else > > it prevents passt sending a signal elswhere even if entirely > > compromised. But we're not really trying to contain the spawned > > process, other than for network purposes. > > Right, not in this case. I waould argue not in most cases, since, since the host fs is fully exposed to the spawned command. > > > Isolating the filesystem would make it almost entirely useless for all > > > the nice debugging / development features it offers (like running any > > > network utility or test), but there's not much we would gain in a > > > general case by keeping the original PID namespace (you don't use pasta > > > to run strace or gdb), > > > > Not to run strace or gdb on something outside, no. But the PID > > namespace makes it more hassle to do things to anything within it, > > such as strace, gdb, kill or re-entering the namespace with nsenter. > > I never needed to do that with pasta spawning a command. But if it's a > use case, this patch would cover that as well, and I guess giving > --no-pidns in that case isn't that much of an overhead for something > that looks like a corner case. Yeah, fair enough. The only downside I see is option bloat. > > > so I think it's an easy, albeit small, win from > > > a security perspective. I'd rather keep it. > > > > For passt proper, yes. Isolating the spawned process doesn't seem > > like it should be passt's concern - podman or bwrap would be much > > better tools if that's what you want. > > Ah, sure, for the spawned process itself yes. > > -- > Stefano > -- 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