From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: <20181112142654.341-1-cyphar@cyphar.com> <20181112142654.341-3-cyphar@cyphar.com> <1ce83cdf6e3168350b69f98f08aaa202bbaa682d.camel@bitron.ch> In-Reply-To: <1ce83cdf6e3168350b69f98f08aaa202bbaa682d.camel@bitron.ch> From: Andy Lutomirski Date: Fri, 23 Nov 2018 08:07:03 -0800 Message-ID: Subject: Re: [PATCH v4 2/4] namei: O_BENEATH-style path resolution flags To: j@bitron.ch Cc: Aleksa Sarai , Al Viro , Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , David Howells , "Eric W. Biederman" , Christian Brauner , Linux API , Andrew Lutomirski , Jann Horn , David Drysdale , Aleksa Sarai , Linux Containers , Linux FS Devel , LKML , linux-arch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org List-ID: > On Nov 23, 2018, at 5:10 AM, J=C3=BCrg Billeter wrote: > > Hi Aleksa, > >> On Tue, 2018-11-13 at 01:26 +1100, Aleksa Sarai wrote: >> * O_BENEATH: Disallow "escapes" from the starting point of the >> filesystem tree during resolution (you must stay "beneath" the >> starting point at all times). Currently this is done by disallowing >> ".." and absolute paths (either in the given path or found during >> symlink resolution) entirely, as well as all "magic link" jumping. > > With open_tree(2) and OPEN_TREE_CLONE, will O_BENEATH still be > necessary? This discussion reminds me of something I=E2=80=99m uncomfortable with in t= he current patches: currently, most of the O_ flags determine some property of the returned opened file. The new O_ flags you're adding don't -- instead, they affect the lookup of the file. So O_BENEATH doesn't return a descriptor that can only be used to loop up files beneath it -- it just controls whether open(2) succeeds or fails. It might be nice for the naming of the flags to reflect this. I also don't love that we have some magic AT_ flags that work with some syscalls and some magic O_ flags that work with others. In this regard, I liked the AT_ naming better. Although I don't love adding AT_ flags because the restrict our ability to usefully use the high bits of the fd in the future. --Andy