From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 879F228643D for ; Wed, 19 Nov 2025 18:34:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763577299; cv=none; b=WcnDu/iOlZ5AfkerMBmeLevVbbYJ07GzvnooIfnrzX1CzbYw60fr37hADy3krUXCtf8QIwtFsRbs/C2aJ+5Sqp+7pApERSxRg95uujw97mkiAZtxgxDzuuppoVk9O8cXmD6t5Y6Gb7Hpky1EU0oNh+XyTHUKC7szIeE1boAC48g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763577299; c=relaxed/simple; bh=iX/ybG6HPqAkpshrGv+ORbH78nPHyHdGlGGvt5nfSZ0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=e4OAOJJz0DXtUzqSxOXlDzfbY6NkW6uwJSEDZNN4cWYJpnJCkSEbYumd0J4k81tTQnVwS/4tdvSSKlsyWkAQrNEjBr1oYnBvUYXuehZKaydrTRAk3gpd4FqSsJHqyx+wYvkpnPFBJ6PlxxqG0Zus4e/guQbu/kZcbKJcE33Yt0E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=M+MKxpAO; arc=none smtp.client-ip=209.85.221.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="M+MKxpAO" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-42b32ff5d10so829604f8f.1 for ; Wed, 19 Nov 2025 10:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763577290; x=1764182090; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=o+POvJ8Ws+92l8UUWtvuhisP25BWZ9HM6mjmX0/Aerk=; b=M+MKxpAOQ2iAgiFIyMffJMePSIJ9l8ZLPS/fIg0ZCVdg0SLKmD66n4MDOIij11O84K COyoEWTgPdrXXicK29ffbTYr5g/3R9foCL5h6yBu8V3xpTT9eNPXpwbIqKtv28er0rJM l6XtdjGVx7pO0lfxYEcX3+YJ25uOY3xf4GyYZVtTkoPvTM8DUSwTGuevIG0WmAmHfCVS KxCI00KMEZYLgoBV15MU08goagRFl+hQH+Qfds+hxGJVpwh98WPcm/XvyGDSICO198YR i5L0NtJSvgTuELvTGynEI+bWu2RfrgfmHqdHWHsnIrIY7TlLIpHLOvJYzcU2iInTSltd 2LVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763577290; x=1764182090; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=o+POvJ8Ws+92l8UUWtvuhisP25BWZ9HM6mjmX0/Aerk=; b=PwnqSHaLLcffvCyi1CsyXbgJP1FbA+79i1+osFcJA0Ff9LBlnGSFoNOC1Rl9qvaTIl hBqgorQRUtmCdU2SvCSkGs4/IjGeZZOyjNr1uwqBy5hgs0zP23kyOGm8vP6bqugMJ3Gh UBcLwsXQUhSaBEe7cvm2ln/1Sx1vnBrpUBDOTBSoa+adwxFQSnRDAdGfiKeDc8DnGjgM 0wE/qNw01YVFQK9RUrk3rLzXT+hiYEMab6TaE6H/tSZCIF9eIBWOQqmYSWxE0lgwTeOh 0jYh53WDbK5xbZTuHGUKmo+IcdBZKcVK4X8qiA3LrVkUrO/UvpP+hLsPgKaH+DLctV4b HFWQ== X-Forwarded-Encrypted: i=1; AJvYcCVcpnvMHmXdjA3i8a/hNTIFx9ySUVduYdL1/VcosLs9fIjxpMc7x+yNHrosoC+RR4qI1JObqiCeBHQJ6/k=@vger.kernel.org X-Gm-Message-State: AOJu0Yy974Hi1GPCUd3p4un/eYcaJ80ppS+fEennqBlRLCRxHNb4TYI1 jae9Yqb0WyAE3CHOAYrvMBIv4ozXdV+sMPovZZcEdwUFkmiBNG/mpFAY X-Gm-Gg: ASbGncv9qHPI8mppxOfn4fmd1oKne1USdOK5P9I8sA+cGl2kpdfflEFljnyPqJYJSQu rm7szwBXOmxzG8vkPu9hTdF+mPdCEICPHOyu9STdY/G2VgN7RRfp32Bfl/SxS/VP6PrTNgVkubN 65+gKgYJQXFj3D5gXNdNYWJZz7wniPg7VHC+F65BunAxSrcP83Q4wbkJTvmDh9gi/o5Zgx3N4fr k5e2DuX6RVtnTf+r7IfXQGZNTra7k7a59YGf9Qh2GzF2cgvzNd0pvqiAC8Jcsuh8Pr2VKSJFOeu hWfvRcfObiZ/SZBsXwPoDCHKpGJRSSFsZntEY2fDSIO5QMeU5NowvLBrctgMWKhCheQRVM0SNeE pc6geYlk32WgXoaYquC3kf66ymsMMdPe5d5MWvAoVyIOp4UjtiBhKz/EziQ1VRYEp4s1XRc/swQ CX7VJtjv/GK0g9U5ItUfHMdyN4bOUIzUuQZH4closF9fO5nGyKd8VsdW6+CUQRiHg= X-Google-Smtp-Source: AGHT+IHnNneLZz+FDHY9DEP2k8i38PWhPNJ2zyasJSA57R/KNoqMioNiRl0N0/4PhXsFU4l3jnTlvQ== X-Received: by 2002:a05:6000:2584:b0:425:7e33:b4a9 with SMTP id ffacd0b85a97d-42cb86c280amr239486f8f.0.1763577289765; Wed, 19 Nov 2025 10:34:49 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42cb7f363c0sm606097f8f.18.2025.11.19.10.34.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Nov 2025 10:34:49 -0800 (PST) Date: Wed, 19 Nov 2025 18:34:47 +0000 From: David Laight To: Alyssa Ross Cc: linux-fsdevel@vger.kernel.org, Demi Marie Obenour , Aleksa Sarai , Jann Horn , "Eric W. Biederman" , jlayton@kernel.org, Bruce Fields , Al Viro , Arnd Bergmann , shuah@kernel.org, David Howells , Andy Lutomirski , Christian Brauner , Tycho Andersen , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: Safety of resolving untrusted paths with detached mount dirfd Message-ID: <20251119183447.7185b739@pumpkin> In-Reply-To: <87cy5eqgn8.fsf@alyssa.is> References: <87cy5eqgn8.fsf@alyssa.is> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 19 Nov 2025 14:46:35 +0100 Alyssa Ross wrote: > Hello, > > As we know, it's not safe to use chroot() for resolving untrusted paths > within some root, as a subdirectory could be moved outside of the > process root while walking the path[1]. On the other hand, > LOOKUP_BENEATH is supposed to be robust against this, and going by [2], > it sounds like resolving with the mount namespace root as dirfd should > also be. > > My question is: would resolving an untrusted path against a detached > mount root dirfd opened with OPEN_TREE_CLONE (not necessarily a > filesystem root) also be expected to be robust against traversal issues? > i.e. can I rely on an untrusted path never resolving to a path that > isn't under the mount root? > > [1]: https://lore.kernel.org/lkml/CAG48ez30WJhbsro2HOc_DR7V91M+hNFzBP5ogRMZaxbAORvqzg@mail.gmail.com/ > [2]: https://lore.kernel.org/lkml/C89D720F-3CC4-4FA9-9CBB-E41A67360A6B@amacapital.net/ May not be directly relevant, but I found 'pwd' giving the wrong answer when done inside a chroot (that isn't a filesytem mount point) after 'faffing' [1] with network namespaces. The basic problem was that two kernel 'inode' structures end up referencing the base of the chroot - so the pointer equality test fails. So you could find the path of the chroot without any help from outside. [1] Brain thinks it might have been an 'unshare' to leave a network namespace that cause the problem. David