Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2257935ybl; Sat, 24 Aug 2019 13:20:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqyRsBZMkO3nzuMnpp4M2YgbDDkI6TKrEWo7qbSSvys2xDTUmTPlzBcsuIzcxdbtiEIUqXlf X-Received: by 2002:a17:902:1a6:: with SMTP id b35mr11508420plb.190.1566678018505; Sat, 24 Aug 2019 13:20:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566678018; cv=none; d=google.com; s=arc-20160816; b=sDZLjzJEZHVzcr1zEyOsaCmv7Fi3pUVkHszJ+M4pZpFBI0nRhkaF/PLXZ2qbv4lSot hbPJrZjtwENhRizrOkmk/VpKMSja9bQ6B6pae/oc2VmFvCMw5dJcLmkLEM141v3fgD34 IEcg0D187AA8GpW955L0UEEnT6EL8dDrlAQAyK/fx7swN4HtK1p3rrc0diUEPBo+kit2 gQfktUHggTw43728VysfDaCxkFBr54T70l1BI4L/StEDRcw8f/UmXNpa6eTGWIRAYH+r kBm+Ytmfk+PmunUyC6ho2CJHjOZ1OpXaNz2q9TBRcQyjlc+Klrlu5bxvFZrh2GVRHMj1 0EMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0zfEO+Of97f0VCldvVRJl3jzEF01O6soGli/loZclzk=; b=tDEfAYwT+7KWC4zL/VV3GxOHR+wsL9bIA/o8W3y42pK3+ynFFqoqfyOhGJtassr895 xrdjPFYw0gPkSNsifKptx02FTxDUrvwSB2l39Uk57QU09/Ntr/aAZqyxbDEjvfzksKJt rJSr30sYuzwRg2pU4R3FpERetdctyO2IhYe0Q82v0/C/JIBWzEmfknfidAuxNG7yrwRV nuerIfDeV2/ZnheQsbTj/qNUZwAjY65FByJ1qELGsChkSzV9xDo93tUNSgahtbTYWvoQ wymesIjFMoRDGN8QEDSMhBcNBSnZGZobLBMOuMuUKOvf1vJrrMed4mqFKzYRM99Z1igF FfYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=CiJfEFfo; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t35si4902982pgm.8.2019.08.24.13.19.51; Sat, 24 Aug 2019 13:20:18 -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=@google.com header.s=20161025 header.b=CiJfEFfo; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727694AbfHXUSM (ORCPT + 99 others); Sat, 24 Aug 2019 16:18:12 -0400 Received: from mail-ua1-f65.google.com ([209.85.222.65]:35578 "EHLO mail-ua1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727019AbfHXUSL (ORCPT ); Sat, 24 Aug 2019 16:18:11 -0400 Received: by mail-ua1-f65.google.com with SMTP id m8so1644998uap.2 for ; Sat, 24 Aug 2019 13:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0zfEO+Of97f0VCldvVRJl3jzEF01O6soGli/loZclzk=; b=CiJfEFfo1GhUFTvULOmIWC5bky0UhNotA9EofhxO4+2Cd9KvnmBRPB6hGuQFhuAXwJ Mf7+XdP/Zb4xXtjIaOfMfbMaQpe98nHR1WFAIDUqUl6lSfoh5N6YkchHMEss2Z7wmXRv mIN1BXAFZpi+SynQvspsYrZxrH8jV01EUoqVt4oI5oVTwO6tctGVNu+Gx+DZX4YcnnWT pUO0Oeafs9qrk8HXoIhQUWukfn1efWZ6t1CZQkpVU6dxRoB/3gD8bO7d0APRfzkEuP01 6A3Oop2AiXmYSlChvGG9uj5KK5z6ZoLIIlfJYts9owMo4k3T92eSIqfy7wB0W5m6uFPz fndA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0zfEO+Of97f0VCldvVRJl3jzEF01O6soGli/loZclzk=; b=KfkXl1ZPTI5L1SAFuAGP/If5vohiVwzLlFFVCgPFd7rDJRX190wd6dmFlUgKNvTQqN vAvVM/UkJlx6+o2zCN6D7nKZKHZXS/V4Y8arBvBp6KCbWfQH0UxvL0FYsvhEcfpTZ7qs wTHlH4SSXu9jdOQZ/aWjp09OaVy4FO4QZpcp1UF9Hy6gvKIfJA4t8U0U9Rn8uNNhquO3 yP4zeikiSQ1RNkFRHB6l5pwT/xUMLWkanXN9oWl3guS7e6hjPbgxFnwbIu/a8oCQDFk8 iIHoiGSAyz6hxYMLFD9yi/ru2MhmVhpmuvKRrn8vf0Z2GQXIA48VXEHs6BdN3+H2vtmD LprA== X-Gm-Message-State: APjAAAW0wl4ogyc1Bt8kLvh32cXN2onmkpCcSYGj1ItH9WtR3pHkPFa8 U4Eg94+mHJcKFPQUjkYftbEReoqjT91Ael3UG7Arrw== X-Received: by 2002:a9f:230c:: with SMTP id 12mr5623819uae.85.1566677889720; Sat, 24 Aug 2019 13:18:09 -0700 (PDT) MIME-Version: 1.0 References: <20190820033406.29796-1-cyphar@cyphar.com> <20190820033406.29796-8-cyphar@cyphar.com> In-Reply-To: <20190820033406.29796-8-cyphar@cyphar.com> From: Daniel Colascione Date: Sat, 24 Aug 2019 13:17:33 -0700 Message-ID: Subject: Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall To: Aleksa Sarai 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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). 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.