Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp3030920ybe; Sun, 8 Sep 2019 05:48:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqxY3t56J7nuFC/tIcE3W9chAUNgnVjgPv1dwiK0C60qJPzg5FS0zGjWc6NjXJZ5zsS5nAE8 X-Received: by 2002:a17:906:400c:: with SMTP id v12mr15016036ejj.15.1567946904015; Sun, 08 Sep 2019 05:48:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567946904; cv=none; d=google.com; s=arc-20160816; b=MhVWKhzIyp3FJJhEvT4yKWCWH6FdGP836bhlfAYcg5o/N3nFHsFYtCpYKP+QO6zs4M qrAouAW5dIM2YLHMoxw4bERODbN/Y9FzEyNvwKAFCtx4hZUFvLvHZ+LMWJIWUHL4dfb9 05JDyDKTWsydxdv8BnFIqym1wSksln+t6PLK/wkvAYCSzrFCOi0XYD40j02UBw44OyKn zhwrlltMRxktkqEORbQHZluOFKT1JjfYGvW1SiBSulg6EhTC6y4BOZZsbOTvVv/AIbbY 7Nq/BELT4JqRV3OilyEZKrSM7JT2k74opyukpgEXQNMmxRARYraQ08NAGPBxFwpsDzxq dZXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=hK4uk1Xt8jVhgNm9y2ucbegczgQlzk4xTCo2+K05hSg=; b=w7gJ36CCVm0/KQUe7+ED7NeuLIlVU9WpxZn/EsAOjAqThhq93Jqd4Cj3HgyResLO1H mzSh/wTA5AdkxB4hd4xPgNMqsn+L5MNRej464n0SP5+joioJI5Xde/CvXAsG9MjoxQUz a5t+/XUVx0lvoo++SKZQi3IuSFfy4xnsNX2LQz9J5aZrUU+JOgyhVubNHJWvG7Ox2IOs jA7yOzuR4c4bbzwnRRg1p+gOGV2zZtqpKoaZ+2rVyA3GjPOPKXlyBDrPKXfJKMYRIAvz W1+FDgmFrtE9IqeybnGZMkaYLFQQwLIRUNuDcz81vkLQUjrE7fpQG8EzKrGykM3koSsw AWrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=BMvFV1UX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m3si5832147ejk.327.2019.09.08.05.48.00; Sun, 08 Sep 2019 05:48:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=BMvFV1UX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405933AbfIGMky (ORCPT + 99 others); Sat, 7 Sep 2019 08:40:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:49340 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731870AbfIGMkx (ORCPT ); Sat, 7 Sep 2019 08:40:53 -0400 Received: from tleilax.poochiereds.net (68-20-15-154.lightspeed.rlghnc.sbcglobal.net [68.20.15.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6CE4A21871; Sat, 7 Sep 2019 12:40:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567860051; bh=8CdC9s2J+EXRB9t2P5assmBfzpxHrY6X7806hW2vZbI=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=BMvFV1UX5X6Uy9Wv1qL/PSUiseB7R2rehCkF1jManrfGr8YI9PSHDWUn9L+S2pFuv RCN9fVNO1dVgQYKSzjsx39Mxn3GBmfn+uxlg8EP9mU5AYcsQNbkdlUXvr6YJL1XW0i aq/hmJ23hyXTE39ZyvTfy0uteQUqAjbcN+eR3HO4= Message-ID: <7236f382d72130f2afbbe8940e72cc67e5c6dce0.camel@kernel.org> Subject: Re: [PATCH v12 11/12] open: openat2(2) syscall From: Jeff Layton To: Aleksa Sarai , Al Viro , "J. Bruce Fields" , Arnd Bergmann , David Howells , Shuah Khan , Shuah Khan , Ingo Molnar , Peter Zijlstra , Christian Brauner Cc: Eric Biederman , Andy Lutomirski , Andrew Morton , Alexei Starovoitov , Kees Cook , Jann Horn , Tycho Andersen , David Drysdale , Chanho Min , Oleg Nesterov , Rasmus Villemoes , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Aleksa Sarai , Linus Torvalds , containers@lists.linux-foundation.org, linux-alpha@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, sparclinux@vger.kernel.org Date: Sat, 07 Sep 2019 08:40:47 -0400 In-Reply-To: <20190904201933.10736-12-cyphar@cyphar.com> References: <20190904201933.10736-1-cyphar@cyphar.com> <20190904201933.10736-12-cyphar@cyphar.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2019-09-05 at 06:19 +1000, Aleksa Sarai wrote: > The most obvious syscall to add support for the new LOOKUP_* scoping > flags would be openat(2). However, there are a few reasons why this is > not the best course of action: > > * The new LOOKUP_* flags are intended to be security features, and > openat(2) will silently ignore all unknown flags. This means that > users would need to avoid foot-gunning themselves constantly when > using this interface if it were part of openat(2). This can be fixed > by having userspace libraries handle this for users[1], but should be > avoided if possible. > > * Resolution scoping feels like a different operation to the existing > O_* flags. And since openat(2) has limited flag space, it seems to be > quite wasteful to clutter it with 5 flags that are all > resolution-related. Arguably O_NOFOLLOW is also a resolution flag but > its entire purpose is to error out if you encounter a trailing > symlink -- not to scope resolution. > > * Other systems would be able to reimplement this syscall allowing for > cross-OS standardisation rather than being hidden amongst O_* flags > which may result in it not being used by all the parties that might > want to use it (file servers, web servers, container runtimes, etc). > > * It gives us the opportunity to iterate on the O_PATH interface. In > particular, the new @how->upgrade_mask field for fd re-opening is > only possible because we have a clean slate without needing to re-use > the ACC_MODE flag design nor the existing openat(2) @mode semantics. > > To this end, we introduce the openat2(2) syscall. It provides all of the > features of openat(2) through the @how->flags argument, but also > also provides a new @how->resolve argument which exposes RESOLVE_* flags > that map to our new LOOKUP_* flags. It also eliminates the long-standing > ugliness of variadic-open(2) by embedding it in a struct. > > In order to allow for userspace to lock down their usage of file > descriptor re-opening, openat2(2) has the ability for users to disallow > certain re-opening modes through @how->upgrade_mask. At the moment, > there is no UPGRADE_NOEXEC. > > [1]: https://github.com/openSUSE/libpathrs > > Suggested-by: Christian Brauner > Signed-off-by: Aleksa Sarai > --- > arch/alpha/kernel/syscalls/syscall.tbl | 1 + > arch/arm/tools/syscall.tbl | 1 + > arch/arm64/include/asm/unistd.h | 2 +- > arch/arm64/include/asm/unistd32.h | 2 + > arch/ia64/kernel/syscalls/syscall.tbl | 1 + > arch/m68k/kernel/syscalls/syscall.tbl | 1 + > arch/microblaze/kernel/syscalls/syscall.tbl | 1 + > arch/mips/kernel/syscalls/syscall_n32.tbl | 1 + > arch/mips/kernel/syscalls/syscall_n64.tbl | 1 + > arch/mips/kernel/syscalls/syscall_o32.tbl | 1 + > arch/parisc/kernel/syscalls/syscall.tbl | 1 + > arch/powerpc/kernel/syscalls/syscall.tbl | 1 + > arch/s390/kernel/syscalls/syscall.tbl | 1 + > arch/sh/kernel/syscalls/syscall.tbl | 1 + > arch/sparc/kernel/syscalls/syscall.tbl | 1 + > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > arch/xtensa/kernel/syscalls/syscall.tbl | 1 + > fs/open.c | 94 ++++++++++++++++----- > include/linux/fcntl.h | 19 ++++- > include/linux/fs.h | 4 +- > include/linux/syscalls.h | 14 ++- > include/uapi/asm-generic/unistd.h | 5 +- > include/uapi/linux/fcntl.h | 42 +++++++++ > 24 files changed, 168 insertions(+), 30 deletions(-) > [...] > diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h > index 1d338357df8a..479baf2da10e 100644 > --- a/include/uapi/linux/fcntl.h > +++ b/include/uapi/linux/fcntl.h > @@ -93,5 +93,47 @@ > > #define AT_RECURSIVE 0x8000 /* Apply to the entire subtree */ > > +/** > + * Arguments for how openat2(2) should open the target path. If @resolve is > + * zero, then openat2(2) operates identically to openat(2). > + * > + * However, unlike openat(2), unknown bits in @flags result in -EINVAL rather > + * than being silently ignored. In addition, @mode (or @upgrade_mask) must be > + * zero unless one of {O_CREAT, O_TMPFILE, O_PATH} are set. > + * After thinking about this a bit, I wonder if we might be better served with a new set of OA2_* flags instead of repurposing the O_* flags? Yes, those flags are familiar, but this is an entirely new syscall. We have a chance to make a fresh start. Does something like O_LARGEFILE have any real place in openat2? I'd argue no. Also, once you want to add a new flag, then we get into the mess of how to document whether open/openat also support it. It'd be good to freeze changes on those syscalls and aim to only introduce new functionality in openat2. That would also allow us to drop some flags from openat2 that we really don't need, and maybe expand the flag space to 64 bits initially, to allow for expansion into the future. Thoughts? > + * @flags: O_* flags. > + * @mode: O_CREAT/O_TMPFILE file mode. > + * @upgrade_mask: UPGRADE_* flags (to restrict O_PATH re-opening). > + * @resolve: RESOLVE_* flags. > + */ > +struct open_how { > + __u32 flags; > + union { > + __u16 mode; > + __u16 upgrade_mask; > + }; > + __u16 resolve; > +}; > + > +#define OPEN_HOW_SIZE_VER0 8 /* sizeof first published struct */ > + Hmm, there is no version field. When you want to expand this in the future, what is the plan? Add a new flag to indicate that it's some length? > +/* how->resolve flags for openat2(2). */ > +#define RESOLVE_NO_XDEV 0x01 /* Block mount-point crossings > + (includes bind-mounts). */ > +#define RESOLVE_NO_MAGICLINKS 0x02 /* Block traversal through procfs-style > + "magic-links". */ > +#define RESOLVE_NO_SYMLINKS 0x04 /* Block traversal through all symlinks > + (implies OEXT_NO_MAGICLINKS) */ > +#define RESOLVE_BENEATH 0x08 /* Block "lexical" trickery like > + "..", symlinks, and absolute > + paths which escape the dirfd. */ > +#define RESOLVE_IN_ROOT 0x10 /* Make all jumps to "/" and ".." > + be scoped inside the dirfd > + (similar to chroot(2)). */ > + > +/* how->upgrade flags for openat2(2). */ > +/* First bit is reserved for a future UPGRADE_NOEXEC flag. */ > +#define UPGRADE_NOREAD 0x02 /* Block re-opening with MAY_READ. */ > +#define UPGRADE_NOWRITE 0x04 /* Block re-opening with MAY_WRITE. */ > > #endif /* _UAPI_LINUX_FCNTL_H */ -- Jeff Layton