From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A89DCA9EC7 for ; Wed, 30 Oct 2019 22:58:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B80C22087F for ; Wed, 30 Oct 2019 22:57:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=osandov-com.20150623.gappssmtp.com header.i=@osandov-com.20150623.gappssmtp.com header.b="ytxpiWCf" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727481AbfJ3W57 (ORCPT ); Wed, 30 Oct 2019 18:57:59 -0400 Received: from mail-pg1-f196.google.com ([209.85.215.196]:36739 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727250AbfJ3W56 (ORCPT ); Wed, 30 Oct 2019 18:57:58 -0400 Received: by mail-pg1-f196.google.com with SMTP id j22so2560834pgh.3 for ; Wed, 30 Oct 2019 15:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3iJAKkJJ1zNiD5ToRiLk2GGyD+vwUWvFX41wfSXW2yw=; b=ytxpiWCfVHhuSE+xqCog0m0AXL1B3dPaRKTHacZP0zCOFyRrV4xmdjq2BQx9srz8Bs 4QZyYC8CNosHZeq6DTYLx8IM++IKHFZCohMBnD6ACBFxjTe5/+XQGSK11ZRXbZLfejl+ sToMO8utduT0t/NE595UePSQv6XVp2T4jPt1ynKayWeNW6cWdqZRtpJ+mw50d0JqFd5H RNQ7Sy58RwIypOIeeGjKs+cujcujmqVRCISK6/T/kzGBHK2bIa5rrt2GZ9zSSo19NKWv MPmytOfjfpn6nZHj6wW0WVdmhNJrbqNL6ZO+z8Hf/iUS40M9Bmnw8RYmw3sqPloL5ziZ cOVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3iJAKkJJ1zNiD5ToRiLk2GGyD+vwUWvFX41wfSXW2yw=; b=BY7aueGSmF71updsmZ/wdufTBsx8370IO9paA6+Vngll8BCBpYuKBfw4Q3qO4tHNfB OuvLrlvf0ZLFzCmq6fimUL2LR5L+5b3kv4iqMnWqzczvO8bKNfjjwrJYGqItyEPEn/cJ awz1orrkUpQQ9LleDYGcuTkdOQa7yi00qnFXQ3ylVYoAMSb1mL+K/fnkMFoD30ftcKIa ojL+7hFEZOPrLACftjz8eLPMV2BtytK+sv1661CdGXz4lWR0yJwXAFVH6KK46yriQVrd /loTW7NLNn13d9hNd35dyQo9BEKkoJqn4ba16vpzvXcwB3QYJYb+MQtW5jVD25iGyNQW Srfg== X-Gm-Message-State: APjAAAVQJEbEIz+OYDqAG+FjWxXaFOmlFVKJTu4GvQOlpEz5ijcTRYlp OlvPZyldoTyRbvMF/sHlkudTkw== X-Google-Smtp-Source: APXvYqwZZqIt951olpu/vwyMMFVU8OrDnaxNtFnNRsSf/YzjHqEUVH1Tg/7QCRt8LkYspXmLhvBYVA== X-Received: by 2002:a63:ce50:: with SMTP id r16mr2097944pgi.253.1572476275923; Wed, 30 Oct 2019 15:57:55 -0700 (PDT) Received: from vader ([2620:10d:c090:180::3912]) by smtp.gmail.com with ESMTPSA id j186sm15676pfg.161.2019.10.30.15.57.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Oct 2019 15:57:55 -0700 (PDT) Date: Wed, 30 Oct 2019 15:57:54 -0700 From: Omar Sandoval To: Aleksa Sarai Cc: Amir Goldstein , linux-fsdevel , Linux Btrfs , Dave Chinner , Jann Horn , Linux API , kernel-team@fb.com, Theodore Tso Subject: Re: [PATCH man-pages] Document encoded I/O Message-ID: <20191030225754.GH326591@vader> References: <20191021185356.GB81648@vader> <20191023044430.alow65tnodgnu5um@yavin.dot.cyphar.com> <20191023121203.pozm2xzrbxmcqpbr@yavin.dot.cyphar.com> <20191030224606.GF326591@vader> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191030224606.GF326591@vader> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Wed, Oct 30, 2019 at 03:46:06PM -0700, Omar Sandoval wrote: > On Wed, Oct 23, 2019 at 11:12:03PM +1100, Aleksa Sarai wrote: > > On 2019-10-23, Amir Goldstein wrote: > > > > > > > > > > No, I see why you choose to add the flag to open(2). > > > > > I have no objection. > > > > > > > > > > I once had a crazy thought how to add new open flags > > > > > in a non racy manner without adding a new syscall, > > > > > but as you wrote, this is not relevant for O_ALLOW_ENCODED. > > > > > > > > > > Something like: > > > > > > > > > > /* > > > > > * Old kernels silently ignore unsupported open flags. > > > > > * New kernels that gets __O_CHECK_NEWFLAGS do > > > > > * the proper checking for unsupported flags AND set the > > > > > * flag __O_HAVE_NEWFLAGS. > > > > > */ > > > > > #define O_FLAG1 __O_CHECK_NEWFLAGS|__O_FLAG1 > > > > > #define O_HAVE_FLAG1 __O_HAVE_NEWFLAGS|__O_FLAG1 > > > > > > > > > > fd = open(path, O_FLAG1); > > > > > if (fd < 0) > > > > > return -errno; > > > > > flags = fcntl(fd, F_GETFL, 0); > > > > > if (flags < 0) > > > > > return flags; > > > > > if ((flags & O_HAVE_FLAG1) != O_HAVE_FLAG1) { > > > > > close(fd); > > > > > return -EINVAL; > > > > > } > > > > > > > > You don't need to add __O_HAVE_NEWFLAGS to do this -- this already works > > > > today for userspace to check whether a flag works properly > > > > (specifically, __O_FLAG1 will only be set if __O_FLAG1 is supported -- > > > > otherwise it gets cleared during build_open_flags). > > > > > > That's a behavior of quite recent kernels since > > > 629e014bb834 fs: completely ignore unknown open flags > > > and maybe some stable kernels. Real old kernels don't have that luxury. > > > > Ah okay -- so the key feature is that __O_CHECK_NEWFLAGS gets > > transformed into __O_HAVE_NEWFLAGS (making it so that both the older and > > current behaviours are detected). Apologies, I missed that on my first > > read-through. > > > > While it is a little bit ugly, it probably wouldn't be a bad idea to > > have something like that. > > > > > > The problem with adding new flags is that an *old* program running on a > > > > *new* kernel could pass a garbage flag (__O_CHECK_NEWFLAGS for instance) > > > > that causes an error only on the new kernel. > > > > > > That's a theoretic problem. Same as O_PATH|O_TMPFILE. > > > Show me a real life program that passes garbage files to open. > > > > Has "that's a theoretical problem" helped when we faced this issue in > > the past? I don't disagree that this is mostly theoretical, but I have a > > feeling that this is an argument that won't hold water. > > > > As for an example of semi-garbage flag passing -- systemd passes > > O_PATH|O_NOCTTY in several places. Yes, they're known flags (so not > > entirely applicable to this discussion) but it's also not a meaningful > > combination of flags and yet is permitted. > > > > > > The only real solution to this (and several other problems) is > > > > openat2(). > > > > > > No argue about that. Come on, let's get it merged ;-) > > > > Believe me, I'm trying. ;) > > > > > > As for O_ALLOW_ENCODED -- the current semantics (-EPERM if it > > > > is set without CAP_SYS_ADMIN) *will* cause backwards compatibility > > > > issues for programs that have garbage flags set... > > > > > > > > > > Again, that's theoretical. In practice, O_ALLOW_ENCODED can work with > > > open()/openat(). In fact, even if O_ALLOW_ENCODED gets merged after > > > openat2(), I don't think it should be forbidden by open()/openat(), > > > right? Do in that sense, O_ALLOW_ENCODED does not depend on openat2(). > > > > If it's a valid open() flag it'll also be a valid openat2(2) flag. The > > only question is whether the garbage-flag problem justifies making it a > > no-op for open(2). > > Consider O_NOATIME: a (non-root) program passing this flag for files it > didn't own would have been broken by kernel v2.6.8. Or, more recently, a > program accidentally setting O_TMPFILE would suddenly get drastically > different behavior on v3.11. These two flags technically broke backwards > compatibility. I don't think it's worth the trouble to treat > O_ALLOW_ENCODED any differently for open(). Ah, I missed that O_TMPFILE is careful to fail on old kernels. My point still stands about O_NOATIME, though :)