From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=GVDWZbXc; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 101855A0265 for ; Tue, 08 Sep 2026 17:32:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788881558; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QQwoV8206ypHf8wU/oZ7dx4RWTQ/HEZHN7nCfSuo+mg=; b=GVDWZbXc8d+AyPJYmoGik5hyk8RAsiRgQXr5ZKkB9EluGwqJF8CfWeDaD57YRJ8FhtInet PyFFCy2E+c2hM1hX2sBEgbAZ5wMA+nxMZLoeF5G8sAYT8llfkDaWVxBT8xD66wNJMMKos5 kP/Fw9ADuBoUrlWV/4/RoysEfv4SfrE= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-664-8pkwb-xKM3uVGbjaAe1fwg-1; Tue, 08 Sep 2026 11:32:37 -0400 X-MC-Unique: 8pkwb-xKM3uVGbjaAe1fwg-1 X-Mimecast-MFC-AGG-ID: 8pkwb-xKM3uVGbjaAe1fwg_1788881556 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-49cc9f5bee2so39765245e9.2 for ; Tue, 08 Sep 2026 08:32:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788881556; x=1789486356; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=QQwoV8206ypHf8wU/oZ7dx4RWTQ/HEZHN7nCfSuo+mg=; b=INyrLERjszmrYhaUMpM6ft5X43TIiJx1YcegXoM++qYe4f7MMsOvazyaOVLkEn0hRT 0W4+YuxbGDaxub/aBLhVvqIMKn62bC4hdzsrwjTox6nyDom2GWEMDGNBZx1Lo8vE/9dB rt9HmrPyW2z6WQ3l7wV/G58Bn+NmZW1XikPzHSaBYgZiZiFgDg3q0dhKCYI3qIbmY1/1 AqEpWE/jCPIA/uOCn9TR0fwVqBZFUxrbTJcINgMUBMfdb843rYor2FYu0zjtVA0VY9jQ w7tzjEauB6q1fcBVA2nZxeBPi32ILhrkYGnMpsoFZasDLSQb+K6GrVLqmkOa7ZnbwIzS SQ3w== X-Forwarded-Encrypted: i=1; AKwUvBx8zR1cipJk8MJbFCjEJOi4kqAT6WekdR2Z/VNzb8oyVbwkjRbo0E6e5v6dI/+ytkM83m5jvFhEhbQ=@passt.top X-Gm-Message-State: AFuF++ky0zmZkTzecUpyqhhTNLtC1hp2bt+j9IGBkBvtHRrOmN74nAV3 RjT5sJ/W1kh0kgoa6pHPlp0qgwOoT1JX9PjM3EvNjWtoUAMP7a4WtP3YlDje/dWTdBScmttj+N/ o4G44QpCXNtICx91vn9z3KdzTBftuYuORR3ZOEAbe7QXNeh1SVPvm6v+6Ivfo4Imp X-Gm-Gg: AYBFou2UehqJmzODK+C3XebbtuqIfpiZqlCSDer4o9u/mhPzFmlLVP/VAiijwYhf7xN FQDe6NNxkzpQNtlhDoo+RM3rNEUEIErECn5a76N7KWxvtdHnS0CQUu7aQ7fvndIFQp2IIDY44rs hNRLOzRbDYmtAErqy32Od0xFBeU2TWErHeVy+g/U6dIipPy+ojFMsDGcmEazzoi/kh2LciqA+X0 Jg+bOW4hHTBdmYKr0PL0sJIjd5E/2VgblljKiB625sccJGllXcXE6JBloEvHW2f2fxFc0tc0szA itMUTZ02x0B/zlHxBxUiCHP8ieMN/l1h1vI38lLtoBnrDRE6zRVEV7bZjCpMoE+eg5kTqkDguWm G3LgsbUsrUp4KuX5ZhEbulbXQBNF5 X-Received: by 2002:a05:600c:8b48:b0:49c:fff9:f684 with SMTP id 5b1f17b1804b1-49cfff9f6efmr216175465e9.21.1788881555862; Tue, 08 Sep 2026 08:32:35 -0700 (PDT) X-Received: by 2002:a05:600c:8b48:b0:49c:fff9:f684 with SMTP id 5b1f17b1804b1-49cfff9f6efmr216174685e9.21.1788881555163; Tue, 08 Sep 2026 08:32:35 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cf772692dsm472359925e9.10.2026.09.08.08.32.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2026 08:32:34 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] pasta: Add --no-pidns to keep spawned command in caller's PID namespace Message-ID: <20260908173233.429652e0@elisabeth> In-Reply-To: References: <20260906131758.121019-1-christian@korneck.de> <20260908114506.49f6ddd4@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Tue, 08 Sep 2026 17:32:34 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: afEIy47qcX0cWf6RD2lrX_QHHAfseqHi0p86tDePuFw_1788881556 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: TNQF5CLSGHUTI6OSS4E46Y4PXSSXQZX2 X-Message-ID-Hash: TNQF5CLSGHUTI6OSS4E46Y4PXSSXQZX2 X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Christian Korneck , passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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. 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. So I find it very useful that it reliably cleans up after my debug / development mess. > 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. > > 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. > > 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