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=E1bRHYtB; 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 8F68E5A0262 for ; Tue, 08 Sep 2026 11:45:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788860712; 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=0tN5JxoCJxV8xK2oogjzEMB7vE7fUh3SKbVE0XEThqs=; b=E1bRHYtBMJU2OlQAWADvm2WP5xrLjqOWgCW/G3jheu0x9qGyuQ5Rba6a7rqC8+sFXRMv7J lC48rO6v/7LLLb+UP5QAC/A7OSfR2+fSE97FelhKkAC7Lji6As/v2+NSfRa6Xpil6bvbF/ +CVM/odBomNLew5yRNcYrWhQhB1Icu8= 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-aQV-OWJoOI6JESBcH26f-w-1; Tue, 08 Sep 2026 05:45:10 -0400 X-MC-Unique: aQV-OWJoOI6JESBcH26f-w-1 X-Mimecast-MFC-AGG-ID: aQV-OWJoOI6JESBcH26f-w_1788860709 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-49cc954a3edso35174515e9.2 for ; Tue, 08 Sep 2026 02:45:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788860709; x=1789465509; 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=0tN5JxoCJxV8xK2oogjzEMB7vE7fUh3SKbVE0XEThqs=; b=pu7uFt2ijhn9FylucqG5oae3KMe4yyXade8+t1huyPH05jbWL+5jlfSBbxjCJIxCDr cMOO9FHqg3HLHCAQQj90uCFw8qn+yqer0+mIVWKIoDvYZfcfAbwEV7OXNYYeIOVQspLT RaYYgacGG6s4JL0fZorCQPzQKO7Pl1Ixwij0uB7EKYa+k2F/spa8uWdCwkgW/oO7ZrpH SfBbz87pHR/nVZD9HFwGfQIq7z6kFwM/iJgZ506t4OA4rZEsTTQP7T7dLQ9mSKlFtXhG OxUPeSfm5Mpx51+l1+j/ZUvoRgwVMYlsBdv+bwTPIxFmTZ6efXj5sCFhXanXJFl6FzcE KAtA== X-Forwarded-Encrypted: i=1; AKwUvBx8NwAYYZoJOoHy/ZR9cE6FQFq4GfBeJsEFzPAowRO2FyVj7+ncB1lBRm73zyNGTuSLGhaL5ILNKDs=@passt.top X-Gm-Message-State: AFuF++kOOZxFN0iz7+4Kh62T4Nf32vIfpIp1YhMhARMibyIYSUaXIaaA 1J77FM+88Az/2SVktcswcdTYRCz0L4UKF6EGQKMlUFe0HqnMIYyNTCdCJXBWLGTLa15UEh+dr5R gA+QvzYBKebYbxpXz1kzWdz41i8iVX5CQRYcpMPDnb28t2WJqHKV4PsItdzQCgtRn X-Gm-Gg: AYBFou2Vy3+bw+jDhGBNcbxRD2oa7MHht2Y/xesBvBSQ2QfHdycHCw2acAp+6SQgMAz W0JaWNRM6WRNkUGGim3KDCxnkh74j0bJoubBcVrLmaQIT+6TvhPGWJGQRhNj6Hir5UczruD6hwT L83aNUEXsytVOy5zODsQ6wmPvyMt/VCtFKdRl+Gu8q91OwTidEyM+Z8MkUVu/2IHiWn48IJSe9N vrw/tOKibBWJ3bsjkne8OkBIr1M1/TYFSIZfLiTtRhtxMfRSl8SsJwSl/yBKmLlx54VOSKZU0VV gLw5xhMU8shQ81mgAKOkxomxdIdGe8uZsepHUNbGO2csOhx4MjAnWM9pfOk/M2GgD4CBKssAth1 Gr1P98Uc2aKE= X-Received: by 2002:a05:600c:348a:b0:49c:fa20:cc03 with SMTP id 5b1f17b1804b1-49cfa20ccedmr215722205e9.26.1788860709390; Tue, 08 Sep 2026 02:45:09 -0700 (PDT) X-Received: by 2002:a05:600c:348a:b0:49c:fa20:cc03 with SMTP id 5b1f17b1804b1-49cfa20ccedmr215721845e9.26.1788860708805; Tue, 08 Sep 2026 02:45:08 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce5952560sm424491525e9.3.2026.09.08.02.45.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2026 02:45:08 -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: <20260908114506.49f6ddd4@elisabeth> In-Reply-To: References: <20260906131758.121019-1-christian@korneck.de> 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 11:45:07 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: HtbAKCHfReY6q3dAnlyoUNuXl4O0VA8nA87ms9Au8Lw_1788860709 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: OQVYEPO4M6JC7SZWG4UM5IDIGEITYZTY X-Message-ID-Hash: OQVYEPO4M6JC7SZWG4UM5IDIGEITYZTY 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 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. 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"): - no need to track child processes: when PID 1 exits, they all terminate, instead of that crazy / buggy hack I implemented before this change - 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 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), so I think it's an easy, albeit small, win from a security perspective. I'd rather keep it. -- Stefano