From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21612 invoked from network); 23 Nov 2020 03:23:40 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2020 03:23:40 -0000 Received: (qmail 24114 invoked by uid 550); 23 Nov 2020 03:23:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24096 invoked from network); 23 Nov 2020 03:23:39 -0000 X-Virus-Scanned: Debian amavisd-new at disroot.org Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1606101806; bh=fGew2T/aaZNfz3188Tq89vWRK8Z7y8LNE+7ESM8gliI=; h=Subject:From:To:Date:In-Reply-To; b=jsErg97XzGCICqpeUR7xVc13cQyH6OtEHnVSWKACUxsv8vKKppII342N/mt33gVpg UL/pPzvtI9u5JEvZAakQWwOIrk/TRvLoYH4uMC139x67A9O63e0eF3KLeD5DhAk4AD qgoUZByMigELtnp++UFH+hT3zWTkdj3BU3YG0s2xGWMdHIEC3kztPabyR0qQQmyc4a wfM4aLLmImKrzYD+e50F7t2ay1YHji4nJaStQDBnjRazM8Giv+2YXfLo5LgJPHXPUV tLEYyzjML5VP0ZtVfjscD6yN4BbcS/MDN+re7k+7W5vrvLduZg2HMRfuAHvP58pCyi atqJwLDCYqQyA== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=C3=89rico_Nogueira?= To: Date: Mon, 23 Nov 2020 00:17:27 -0300 Message-Id: In-Reply-To: <97dd3cf7c69673e5962e9ccd46ea5131@ispras.ru> Subject: Re: [musl] realpath without procfs -- should be ready for inclusion On Sun Nov 22, 2020 at 11:03 PM -03, Alexey Izbyshev wrote: > On 2020-11-23 01:56, Rich Felker wrote: > > I originally considered keeping the procfs based version and only > > using the new one as a fallback, but I discovered there are cases > > (involving chroot, namespaces, etc.) where the answer from procfs is > > wrong and validating it requires basically the same procedure as > > implementing it manually (walking and performing readlink on each path > > component). > >=20 > Pity that the simple and fast procfs-based implementation goes away. Do > you have any specific example of a wrong answer from procfs at hand, or > at least a more specific direction to look at than just > "chroot/namespaces"? bubblewrap (when driven by Flatpak) is one such software. Void carries a patch [1] with NetBSD's realpath impl to work around this. Without it, launching flatpak applications sometimes didn't work at all. - [1] https://github.com/void-linux/void-packages/blob/da86d30391e2b3535e8f= 9dfae452d2b362887e41/srcpkgs/bubblewrap/patches/realpath-workaround.patch