Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2214006ybl; Thu, 29 Aug 2019 05:19:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqwxP39+0voDpKwQQa3eYdT2/LwyBt2DunXIcTXe/yDOBPcpm21Enc0iZ5fautYD2kk9zGkc X-Received: by 2002:aa7:9473:: with SMTP id t19mr11372576pfq.141.1567081142098; Thu, 29 Aug 2019 05:19:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567081142; cv=none; d=google.com; s=arc-20160816; b=QtYZxYiyBzNJ2yQiG3Wvd9vo97P/SOPKSNyDFw9dDvGp6EbhKrxBzV52hdc8WZi2ry WjjGdo4UpOw4KofrJ5EMkNxADld45Ld/MPc+wHn00xRCBJr4IIyh3qWk5BQU/oQN3RaE 5aiWzw8avQFdyWoVcMRgEsWz2zFRRUbLE4FeQuhr949NDGy8zkiFEvAugRv3C953ajvr or13RB05iLMo94D4Pmh0M4e87996dF9WSAZrpaLP23sas4NFJOdFm46zONfGUB0E90KO /Ydsrric5PJ74Z7matcPkwz0ppIS9GNE5eh6y1ahd8kT2W1315sQClKKHtDPKRK3n/2v 5goQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=MTnS4vo0hFgVVZn/tAJDDm7A+1U+gA4BFaBJ07szU1o=; b=II7N6EjHmUYk6VqpJ+ZTd0jHsdTouTKdlWEEukJAsj6ZQCbEl6r0/zTgCmKD82g436 g4OysYFKUrZXb8WeroBRlLt90LHHcFAB3jiKM80P6IjRAWNJtureOIRz1mvcU6ilKOzA tknN1b3LSwzVSykP9oparFqF34nATfjLtwEhuSmnxmMe58Q4EDU3MLXop0Dg8WDY5gfv /mWdR3SMpuo9cV1yeB+sOwFgsYCcFRjIIo3yI7UBk0myKCHrKTjCIsBbZbdpghPTxLd9 aqJGO2RalB+bBFqarV2HwOZ1pVv5486dWwkiFO56qzF7hTW1w+qTPZqtzq+lgjLXFGbz WPtA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d25si1835152pge.301.2019.08.29.05.18.42; Thu, 29 Aug 2019 05:19:02 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727914AbfH2MQJ (ORCPT + 99 others); Thu, 29 Aug 2019 08:16:09 -0400 Received: from mx2.mailbox.org ([80.241.60.215]:28272 "EHLO mx2.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727174AbfH2MQI (ORCPT ); Thu, 29 Aug 2019 08:16:08 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 2ACB4A1069; Thu, 29 Aug 2019 14:16:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id WXJzDwa0kR9t; Thu, 29 Aug 2019 14:15:51 +0200 (CEST) Date: Thu, 29 Aug 2019 22:15:27 +1000 From: Aleksa Sarai To: Daniel Colascione Cc: Al Viro , Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , David Howells , Shuah Khan , Shuah Khan , Christian Brauner , Eric Biederman , Andy Lutomirski , Andrew Morton , Alexei Starovoitov , Kees Cook , Jann Horn , Tycho Andersen , David Drysdale , Chanho Min , Oleg Nesterov , Aleksa Sarai , Linus Torvalds , containers@lists.linux-foundation.org, linux-alpha@vger.kernel.org, Linux API , linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Linux FS Devel , linux-ia64@vger.kernel.org, linux-kernel , "open list:KERNEL SELFTEST FRAMEWORK" , 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 Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall Message-ID: <20190829121527.u2uvdyeatme5cgkb@yavin> References: <20190820033406.29796-1-cyphar@cyphar.com> <20190820033406.29796-8-cyphar@cyphar.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ys4y6f5eyfdosi3x" Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --ys4y6f5eyfdosi3x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-08-24, Daniel Colascione wrote: > On Mon, Aug 19, 2019 at 8:37 PM 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. The open_how struct is padded to 64 bytes > > for future extensions (all of the reserved bits must be zeroed). >=20 > Why pad the structure when new functionality (perhaps accommodated via > a larger structure) could be signaled by passing a new flag? Adding > reserved fields to a structure with a size embedded in the ABI makes a > lot of sense --- e.g., pthread_mutex_t can't grow. But this structure > can grow, so the reservation seems needless to me. Quite a few folks have said that ->reserved is either unnecessary or too big. I will be changing this, though I am not clear what the best way of extending the structure is. If anyone has a strong opinion on this (or an alternative to the ones listed below), please chime in. I don't have any really strong attachment to this aspect of the API. There appear to be a few ways we can do it (that all have precedence with other syscalls): 1. Use O_* flags to indicate extensions. 2. A separate "version" field that is incremented when we change. 3. Add a size_t argument to openat2(2). 4. Reserve space (as in this patchset). (My personal preference would be (3), followed closely by (2).) The main problem with (1) is that it pollutes the open(2) and openat(2) syscalls with new O_* flags, which is probably not a good API decision (syscall flags are already "bad" enough, let's not throw a bunch of no-ops into the mix). (2) is mostly fine except for a slight issue of ergonomics (glibc would have to auto-fill the version field or make wrappers in order to make it easier to use sanely). But this does have the benefit that we could re-arrange fields (not that this is something we'd want to do anyway). Both (1) and (2) have the problem that the "struct version" is inside the struct so we'd need to copy_from_user() twice. This isn't the end of the world, it just feels a bit less clean than is ideal. (3) fixes that problem, at the cost of making the API slightly more cumbersome to use directly (though again glibc could wrap that away). And the downsides of (4) are pretty well discussed already. --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --ys4y6f5eyfdosi3x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSxZm6dtfE8gxLLfYqdlLljIbnQEgUCXWfB2wAKCRCdlLljIbnQ EljcAQC+BitddeHjv2a9yspU0gLaZB6nn8UBahZIqiE8+4xUoAEAuibGdlSM4ag8 ZYal7PGiNelUZH1S6GPHj1bvVNNGOQ0= =OczH -----END PGP SIGNATURE----- --ys4y6f5eyfdosi3x--