From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 473DA936A; Mon, 27 Jul 2026 11:01:40 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 68E9E935F; Mon, 27 Jul 2026 11:01:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) by atuin.qyliss.net (Postfix) with ESMTPS id 74725935B for ; Mon, 27 Jul 2026 11:01:36 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id BF5BC1400030; Mon, 27 Jul 2026 07:01:34 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 27 Jul 2026 07:01:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1785150094; x=1785236494; bh=oIctZpFHwk XP577ZhPLUYbwpXOPU9KfyzbKCSJrbWCY=; b=O+5qUoU8kMF8CzgBRwOqViJTvS BTVv24PFz2k/Ts/Awc0CidOgssuNvXihmgtFISsa7gRgdrjv/BhrZgn14a2pghTs T9DJPp1j3HhvLh38FBzeiLG0uVWj4o5DjKz9/zPnkkIAwspOEjI51to+ddunQAVG qVetrJoE+wZwrOmIOTHhXOWs2VCs+YOgzcGKTF7i8TRYTB1OIrEGanKK8CFhPGuZ nSqDQCzhq6k9gpAC7QpoDEBqb6YY/ayXD/p21UyPEZo9IzqF60Su4ypn85u3KP3R FDlEtG/C13zMwbniZ76GCH8APDljKkM3+WTpLo5qzM65QDrzFrbopdtZye5Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1785150094; x=1785236494; bh=oIctZpFHwkXP577ZhPLUYbwpXOPU9KfyzbK CSJrbWCY=; b=cu+rN0fCkE+9JLatbcW39t4wYbfxtBnwVLjgoKylRfnAZDtAHVj Mhx/++cb1iNv4v5nNuauloywHcTNvTR7+eV53aKneF86MBS2TJ8nmc+4pry3esYv K4mdNax5ZnqvXHYCjB9LmoQxlr5ysZVIheqRu0486AiqYEOSjiuGrpjMQ8QViniG 41CgZ4gr6kxx0uXF1zqpZefeHPiofAZne3PF1sALgmzg6zvWfruKfYh2aH8wSJSL NpJMzqvDfRH15CtMRH/nS1SFwxrtBySu6EGfQ7uWnYnMQVgwBl6tqNcha2ctKGgw hLVezJ+lHazVtxwV1RmVsbNIrC5Zz4s4Prg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFx7jXKWpR0x9i4FdbjAegT+FjfUtAvS/u9RJJJwRmg1xgQfIRP6HWxNpwFRKmyW6 B3mxnNkrPLVnnmzCxKRL1VdgCkx7U40dwLye7SDzkAy3M1me4Asj7NqwHnRpZcIBTyapAv rw26kIuebO6wE4Nbe4SJPXeWRfSTuH82/3IN4ZEIv9piV4squBVzhu2wP06g65COitHj/s K5GmFkxD3fZqC1dwLs76sR7wYVnS8ouLBFAGleQ8MbXm/ugXQOydlp6+cakrkkBNcbJG9T G4feJDOIAxndKmStd0VKKMy08fy6OOcgx3NY+jfKXgdM2kSlhqNuuNAZxKb7sXifI63YqO nYgVc4ozqENzM+zxziaegbe4qVN8HXGar09c4IbO3xMZC9kQMig2o6mjZvgMUiyrbf2jbT r5uMPS8W0lFMUB/z7a19hmq3Ul7h9FAw9JVDDea8bgSlKjV62kT5tQrnZZnFGLr3W07ddu 3be8w3rzdCk6Abtt7zbgWOvdP24ohxMSRnLnygbMTToHCPVPV9L3/gL4oCLn5MlkcTLWX+ DP2rcLqM1tkVpjyfUuWjJ+IEpEGItNln9bgk0nOPQJTAX6nc6eXZUnl+oRj2Etm1t1ZALD JlIyyoD5YiJ7PBMPGm3siX8DRKHVQyBHe37+FNM+ugg734vARGtkky5HcImA X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Jul 2026 07:01:34 -0400 (EDT) Received: by fw12.qyliss.net (Postfix, from userid 1000) id 6078BC4D6B62; Mon, 27 Jul 2026 13:01:33 +0200 (CEST) From: Alyssa Ross To: Demi Marie Obenour Subject: Re: Potential improvements to mount-flatpak In-Reply-To: <92ab45ab-a124-4edc-b5ea-d35621ce0e53@gmail.com> References: <1bebc170-25cc-4c25-8b93-eef50e0e2685@gmail.com> <87zezjtp46.fsf@alyssa.is> <92ab45ab-a124-4edc-b5ea-d35621ce0e53@gmail.com> Date: Mon, 27 Jul 2026 13:01:31 +0200 Message-ID: <87qzkolmr8.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: X4TDOY7IJBPMKVX7YYIPL4K3XSWR2S4Y X-Message-ID-Hash: X4TDOY7IJBPMKVX7YYIPL4K3XSWR2S4Y X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Spectrum OS Development X-Mailman-Version: 3.3.10 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Demi Marie Obenour writes: > On 7/22/26 04:17, Alyssa Ross wrote: >> Demi Marie Obenour writes: >>=20 >>> - The code doesn't validate the user-provided app ID, resulting in >>> worse error messages than otherwise possible. App IDs are always >>> D-Bus well-known names, so there is no risk of the rules changing >>> in future versions of Flatpak. >>=20 >> Even though Flatpak 2 won't use D-Bus? > > I think I forgot that. Is there a document with the list of Flatpak > 2 changes anywhere? I think the talk from Linux App Summit this year is probably the most comprehensive thing about it so far. >> I'm not sure I see the value? Does normal Flatpak do these checks? >> I don't think we need to check everything that could possibly go wrong >> if it wouldn't be a security concern. > > I don't see any reason either. There is a trick one can do to > improve worst-case runtime, and that is to not use RESOLVE_BENEATH > or RESOLVE_IN_ROOT. Instead, one uses RESOLVE_NO_SYMLINKS | > RESOLVE_NO_MAGICLINKS and checks that the path has no ".." components > and is not absolute. My understanding is that RESOLVE_BENEATH > and RESOLVE_IN_ROOT require heavyweight kernel-side checks to guard > against race conditions, and these can produce false positives. > The other approach doesn't require these checks and so is more reliable. > libpathrs resolves this with an ugly retry loop. > > It's up to you whether this change is worth making. Sounds like premature optimization to me. All else equal I'd rather have code in the kernel than in Spectrum. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQGoGac7QfI+H5ZtFCZddwkt31pFQUCamc6iwAKCRCZddwkt31p FVzJAQDJDsQgnvAHJyQPU25z+Q4dafLLk738HNyF7y8C+hrgZQEAvDZOTdtFI7H4 eyV/+KDhJiWbhRf+17QrRohRK1VXMgg= =gnri -----END PGP SIGNATURE----- --=-=-=--