From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=fail (p=quarantine dis=none) header.from=redhat.com 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 A45E05A0271 for ; Wed, 04 Nov 2026 00:59:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1793750352; 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=PrMCZ4x6a7rNn5UxnVtx9HEOEcz51aaKYE95puYR3/Q=; b=QY0+VJErlGpVXz9TbSy4yFuTARxqKxveaRb7bEi/DOIXlhFdpyd5FF0HQtmL9w6BBbUmP/ BJVF5dZt9+hyM9aPwJ6tftHbzvwkJaZIGPzOP0VHqMZu9uYsORMMKGTJ3vDbSYXFKMye84 qjJsTv5M5BzdskwXla7s1RAAvs02mqw= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-652-6Zz1t219N2STxtUGREky_A-1; Tue, 03 Nov 2026 18:59:11 -0500 X-MC-Unique: 6Zz1t219N2STxtUGREky_A-1 X-Mimecast-MFC-AGG-ID: 6Zz1t219N2STxtUGREky_A_1793750350 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-48e0ef019a4so111448f8f.3 for ; Tue, 03 Nov 2026 15:59:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793750350; x=1794355150; 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=PrMCZ4x6a7rNn5UxnVtx9HEOEcz51aaKYE95puYR3/Q=; b=kZCulIzIxD/2Kw8B4xqOoPXgsiB7h/q+rNY315BNRXnbXKzJKUXtn5LJdP32dlTVLM gVXk6JOLNMYUHX2Zu0F4ns/5CYcCAzYwHjQkkTDT5tZmUGAf6Y2baBTc4bgvg/jZhueO xM7kYWG2r1qFagjCneEBNxA7sjEDIcYfB9Icmkct1C6SxF9spKWQi+IFlAT5cN4zDOcj arvq9y6LrP4XhVeDcXcyi9yu4hZGKwDT6SsjCx+pqT4dXyFlAgRbKDRi/rfGqNrJXkej TIMNEZxCCgPjOQKaOjQZSwlQ8dxS/qM+7Zx2357Lptarw/aOrtrVxHX3vGaGbFwYXxap hrjQ== X-Gm-Message-State: APuU4Z+aDVg9KD0wC9+XT1mt8MwhyhN6Atbrd+TKxjeAlBJe/PRiuIzV GqfJe7zU1SiCabFD/Awx05Xpivy4EBL4+03bSz27WzhjMFY6AdIhntw7rXotRSV5KF4aHo6P0ck BFy1pvSNZT3iYu0X91Xw7YmSb6G8Z8PmJ6T9PYNeSLwpT/vlGG+LSM5vjPeq0XfkUiPmWmW+tXb lUuNbrJ3Gb8P1DEBOysD3k1M4ewLF782tZufVV X-Gm-Gg: AYBFou372g8WckkS7MjPCphNb2LJfprZzRg6+uTpUQx38RpkzMvum+hWmK/4mBnjb1g 5KW3uKefDfFCkwn8JWeOpu1qhsVIeiavqZt98TV3Vjb8dFxTzlJeKw0Pv2NRbzKcoI0E3J7aSPg Lj0CkHoV9q+2eAQ6PdB56isBZLlcw0BLzu8eew/4Jh4gOlHvqOuf1KTyb/PZm4N2F8FEiwQbKoI DMij4h5+pmQ9V7geZ8Y67NCWQ2JE8affsmtn0r6UXaPzLfjKR+OMkL8dT9/E0JEvRF16dZT7r8k PtzECmU2MKX35zYb9q58SKkSviQwu/MNzSkoXdQTbf+pmBMpLoYc73ot5b+V42bjzRyS29RyCzj B2AtOInWSiM5A0eVPUHhzDmdanTaXpdUtIStsUb2Jial7wzKAPbXxHidan8FSj6lmLXT93NIVoP xyjQmuSJkx X-Received: by 2002:a05:6000:22c2:b0:48e:2980:d396 with SMTP id ffacd0b85a97d-48e6e50da28mr35297182f8f.37.1793750350045; Tue, 03 Nov 2026 15:59:10 -0800 (PST) X-Received: by 2002:a05:6000:22c2:b0:48e:2980:d396 with SMTP id ffacd0b85a97d-48e6e50da28mr35297139f8f.37.1793750349366; Tue, 03 Nov 2026 15:59:09 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48fea180eaesm772082f8f.2.2026.11.03.15.59.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Nov 2026 15:59:06 -0800 (PST) From: Stefano Brivio To: "Lawrence, Richard E" Subject: Re: [PATCH v3] pasta: Add --pass-fds option to skip closing file descriptors Message-ID: <20261104005905.67ee738c@elisabeth> In-Reply-To: References: <20261026170345.634781-1-rlawrence@tamu.edu> <20261028233813.1bf26f42@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: Wed, 04 Nov 2026 00:59:06 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -76iaX7VvRw13IGaq0Qcsk0-9pgmG-eGfCxuRUqAjX8_1793750350 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: W34ARIZETDZB3SC5NK6235F2LWLUMENK X-Message-ID-Hash: W34ARIZETDZB3SC5NK6235F2LWLUMENK 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: "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 Thu, 29 Oct 2026 17:01:46 +0000 "Lawrence, Richard E" wrote: > Howdy Stefano, > > I had sent another message to the PATCH v2 thread, but it seems you > missed it. Copying inline below (>>) so you don't have to go hunting > for it. Indeed, I missed it (even though I received it, I just skipped it somehow, sorry). Thanks for the summary. > > ## Re: long option index. > >> It turns out the minimum index for a long option is 2, not 1. > >> conf() already correctly does it that way. > > (continued...) It's because long option index 1 is reserved for > positional arguments or something like that (forgot the details). Oh, oops, right (I thought just 0 was reserved, but that's not the case). > ## Re: relocating fd_tap conditionally > >> I think I misunderstood your question about unconditionally > >> relocating the fd_tap. Please clarify: are you suggesting that we > >> should skip relocating fd_tap when we also skip closing leaked > >> file descriptors? That design would not cause any of the bugs I > >> imagined. For example, it would never affect passt mode because > >> skipping is forbidden in passt mode anyways. If the user does tap > >> | pasta --fd 0 --pass-fds cmd then the fd_tap stays on stdin, so > >> the spawned command gets it on stdin; that is technically a > >> feature ("--pass-fds preserves file descriptors"), but I still > >> think it's very weird behavior. > > (continued...) But, given your more recent comments, I think I am > still misunderstanding your question about unconditionally relocating > fd_tap. So I need to ask a different question instead. Please > clarify: is it ever OK to leave the fd_tap on 0? If we can leave > fd_tap on 0 in pasta mode with pass-fds, then that greatly simpifies > the logic. I'm not sure, I instinctively don't see a big issue with that, but you had valid reasons to suggest we should avoid it, so I thought we should avoid it. My suggestion on v3 didn't actually question that part. I was suggesting the condition to move fd_tap would be: /* Move the passed fd to a more convenient location (3): * - on --pass-fds, only if it might conflict with standard streams * - otherwise, unconditionally, to keep close_range() below simple */ if (c->fd_tap >= 0 && (!c->pass_fds || c->fd_tap < close_from)) { meaning that it's never left on 0 anyway (close_from is 3). That won't work for the case below as you noted, though. > ## Re: dup2 vs fcntl > > Please allow me to clarify: the reason I switched from dup2 to fcntl > is because I imagined a scenario where the user wants to both: > > 1. > pass the tap fd to pasta on 0, and also > 2. > pass something else through to bwrap on 3. Oh, oops, I see. > For example: > > ``` > exec 3<<<"Hello from FD 3" && tap | pasta --fd 0 --pass-fds bwrap > --bind-fd 3 /hello bash -c 'cat /hello | > send-it-to-the-internet-or-something-idk' ``` In that scenario, using > dup2 is a major problem. It closes the existing FD 3 and puts the tap > there instead! So the user is now accidentally sending the tap to the > internet instead of the data they intended to pass on 3. > > One possible solution is to leave the tap on 0 instead. Could some users perhaps actually want that? Say: (something) | pasta --pass-fds -- pasta --pass-fds -- bwrap ... But what you propose below still looks slightly preferable to me. > (previously...) > >> If you do insist that this weird behavior is in fact the correct > >> behavior, then we can demote the fcntl call back to plain dup2 > >> with a comment that explains it is safe to close and reuse fd 3 > >> since the user did not request to pass-fds. This comment is > >> necessary to prevent a future bug if someone refactors the code > >> carelessly (dup2 closes fd 3 when user wants to pass fd 3). Please > >> let me know if that change is still what you want. > > I call this the "unsafe" option. I can imagine that leaving the tap > on 0 could cause bugs It shouldn't, but avoiding that would be worthwhile because of point 5. in: https://archives.passt.top/passt-dev/20260715183946.6121580a@elisabeth/ that is, if 0 is never a valid file descriptor, we can use it (implicitly) for initialisations, which avoids the need for a fair amount of code (and a bit of binary size as well). > and I imagine that leaving dup2 in the code > could re-introduce the clobbering bug at a later time. I don't think it's such a big issue as the code dealing with this is all in the same place and relatively easy to observe. > ## New Proposal > > I propose to always relocate the tap above 2, to avoid bugs, but the > system call we use can be conditional: > > * > dup2 when we're closing fds (because it's the easiest) and > * > fcntl when we're leaving them open (because it's the safest) > > that seems like the best of both worlds. Yes, I tend to agree. I have no idea what the resulting complexity might be. If it's too complicated, I'd say let's just allow 0 as fd_tap... up to you. The purpose of my comments to v3 was to ensure we don't make things more complicated than they need to be, but I guess some additional complexity is needed in any case after all. -- Stefano