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 21A85CA9EC7 for ; Wed, 30 Oct 2019 22:46:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DFC9121924 for ; Wed, 30 Oct 2019 22:46:11 +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="bkZBZ57m" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727440AbfJ3WqL (ORCPT ); Wed, 30 Oct 2019 18:46:11 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:34123 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727294AbfJ3WqK (ORCPT ); Wed, 30 Oct 2019 18:46:10 -0400 Received: by mail-pf1-f194.google.com with SMTP id b128so2725818pfa.1 for ; Wed, 30 Oct 2019 15:46:08 -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=PnrfXeYVRnpGVPGiQDcbW5SLqkZubZ+o9/pPkDpKRLw=; b=bkZBZ57meOngOGFWqgT5tJ/VVPrpfwkqsGbUVC907SVJYvcwR7C7b06NpUvxn9YGsB g+BiTZl9eHlishVM5xWNwl8ci/CTMSziIL/JSijnZhCVj7MH59NANsRpnDuIN/nVz15s k9Zb+Je5/nezygJuhSKvSjcW8+eGRONrr263WBn7hIB1K2BqH82J7Mxzik2VBVARSCcw mU4NFZFindc3TWrhDteecyPufF9Fy8T0AK+s0kCV9a0nvkli3jAfk5WhomQGMU/kb9G4 +dDuFKJ3FNf0VOfgQcX+EDtMCWoCtNWyTh93zoeeMaf5OPHWjTekPJAgBEn5wA8VSiU0 YmIw== 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=PnrfXeYVRnpGVPGiQDcbW5SLqkZubZ+o9/pPkDpKRLw=; b=lHdqEbmaCeJUO+szg2zgv9u9xQI4dqLFqKtZYO1caTTh+YRuzelHXRbnhEdeFra3aQ DJc5521H67JeSQ5cOAoGZ7rsIsWBcpXUwrxoTP1qZeNbEy8DdY7PGbRqCxoKEzg/BR5Z x3S8OLMjdTf30hpm4x2dvzc70j31AvX7WkWmFtzTYHLzjg52tVhjnPTJLbCmRYJjM3zo peC1kW11qSbNA5Y4+QTCJjjGrb/lSmvrWbjxHsEbr5qOZK11UtlOZwTcfnSIGXyOyGvJ 86vKoPqM/pAdEPot3OlcYvv4vfr1UAM4J+zq5MHUVNEGnEhv0J39oMP4H/LHGMFxfiTI ebJg== X-Gm-Message-State: APjAAAX2vzPTUxpdxll8kGw4FejQxtuytQ8N/qI5XIimHSNO1NAQ0gSh e2KBCfN8kphu7+TnrPN+RksGAg== X-Google-Smtp-Source: APXvYqzUxjMMwehyd2VV+tc2gBZO2f30q1yw7y78xZS39vYxlWAxedexkNC5tZJkUonFDc7ZstjC/A== X-Received: by 2002:a63:3e43:: with SMTP id l64mr2048023pga.51.1572475567838; Wed, 30 Oct 2019 15:46:07 -0700 (PDT) Received: from vader ([2620:10d:c090:180::3912]) by smtp.gmail.com with ESMTPSA id f17sm906751pgd.8.2019.10.30.15.46.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Oct 2019 15:46:07 -0700 (PDT) Date: Wed, 30 Oct 2019 15:46:06 -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: <20191030224606.GF326591@vader> References: <20191021185356.GB81648@vader> <20191023044430.alow65tnodgnu5um@yavin.dot.cyphar.com> <20191023121203.pozm2xzrbxmcqpbr@yavin.dot.cyphar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191023121203.pozm2xzrbxmcqpbr@yavin.dot.cyphar.com> 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 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().