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.3 required=5.0 tests=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 22873 invoked from network); 23 Nov 2020 03:34:17 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2020 03:34:17 -0000 Received: (qmail 3137 invoked by uid 550); 23 Nov 2020 03:34:15 -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 3113 invoked from network); 23 Nov 2020 03:34:14 -0000 Date: Sun, 22 Nov 2020 22:34:01 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20201123033400.GT534@brightrain.aerifal.cx> References: <97dd3cf7c69673e5962e9ccd46ea5131@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] realpath without procfs -- should be ready for inclusion On Mon, Nov 23, 2020 at 12:17:27AM -0300, Érico Nogueira wrote: > 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). > > > > > 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/da86d30391e2b3535e8f9dfae452d2b362887e41/srcpkgs/bubblewrap/patches/realpath-workaround.patch FWIW this seems to be a reason for needing the real implementation like proposed, but not a reason for getting rid of the proc-based code path. The reasons for that I mostly covered in my reply. Rich