Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp2363851ybf; Mon, 2 Mar 2020 07:12:48 -0800 (PST) X-Google-Smtp-Source: APXvYqzMmHTvIPkTPxAaXtaXPg+28Et3o3Z8oKCBVrwid2qsyrcWnKe5N4+rNevz27bBE5W+5ye/ X-Received: by 2002:a05:6830:1e2b:: with SMTP id t11mr13697220otr.81.1583161967899; Mon, 02 Mar 2020 07:12:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583161967; cv=none; d=google.com; s=arc-20160816; b=shsP9IOxiCZCh+k5Ao7/KFL7V8ZhyENcyB8XFOImo5WtkIsnC9TE5J8IyfDhtkxhce NO11u3zOavafe+/II9agJkrtovvz32jpLTHXuAlaUYRiZUnFymmkv/bxQQSTfwm6M8wk oW6GdIB+RVC5bYwAkW+SzJwDZIFSJJEuYy8LHcrLJcpQkAGZPad6inlszM9py63HuIPa s/L0zB0Mo7q2QOhU+5nbSNtccsNO8Ynl0bNCWmQn7pDx+hEl2s8klQdEmATat5aKTek7 JKxRAIlCElUltG4OUlFebi9IUs76TIT24J3ICHZo84xTIVnCLwyO3SUyt7WgXapOh1Qx DyBQ== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=9RgAwzU4p2iXUVb3whDva90TiosQ7/qD1JKMydBHd4o=; b=EY/S/56TgDQ4oW6fUioTcrStvDeWq6+Ag5tAEo9WyAkswFyqSuaRCmxG+OOIhH7zS2 PENi5ptM/0QY+zPmiVBkAZDoUKwZI148lszEGbdT4NOUJupFON2F8jW/OUmbVhRNe0ev frPvLsgMc3XFNJA3+7sVKxZIfa45Pw/H67FD0/CxhdCJ2z529QPYVKZ6K7Ngw+vVQihq rUEL44gDDNALEIL3OoBWtnEppZ6mMiyfiQ0uHSUF+HQ9UpwoSvol5ECw8Lr/+K8TOl+0 vhjmvpg8S37I+PzYNuHXrYKknX4atP4xn+Yv+zuhRM1j3yuALQgsLf9aZn5HOJJHvetW hzEg== 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 l21si6367715oic.126.2020.03.02.07.12.36; Mon, 02 Mar 2020 07:12:47 -0800 (PST) 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 S1727363AbgCBPKw (ORCPT + 99 others); Mon, 2 Mar 2020 10:10:52 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:34163 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726831AbgCBPKw (ORCPT ); Mon, 2 Mar 2020 10:10:52 -0500 Received: from ip5f5bf7ec.dynamic.kabel-deutschland.de ([95.91.247.236] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1j8miV-0001DR-2G; Mon, 02 Mar 2020 15:10:47 +0000 Date: Mon, 2 Mar 2020 16:10:46 +0100 From: Christian Brauner To: Florian Weimer Cc: David Howells , linux-api@vger.kernel.org, viro@zeniv.linux.org.uk, metze@samba.org, torvalds@linux-foundation.org, cyphar@cyphar.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Have RESOLVE_* flags superseded AT_* flags for new syscalls? Message-ID: <20200302151046.447zgo36dmfdr2ik@wittgenstein> References: <96563.1582901612@warthog.procyon.org.uk> <20200228152427.rv3crd7akwdhta2r@wittgenstein> <87h7z7ngd4.fsf@oldenburg2.str.redhat.com> <20200302115239.pcxvej3szmricxzu@wittgenstein> <20200302120503.g5pt4ky3uvb2ly63@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200302120503.g5pt4ky3uvb2ly63@wittgenstein> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 02, 2020 at 01:05:04PM +0100, Christian Brauner wrote: > On Mon, Mar 02, 2020 at 12:52:39PM +0100, Christian Brauner wrote: > > On Mon, Mar 02, 2020 at 12:30:47PM +0100, Florian Weimer wrote: > > > * Christian Brauner: > > > > > > > [Cc Florian since that ends up on libc's table sooner or later...] > > > > > > I'm not sure what you are after here … > > > > Exactly what you've commented below. Input on whether any of these > > changes would be either problematic if you e.g. were to implement > > openat() on top of openat2() in the future or if it would be problematic > > if we e.g. were to really deprecate AT_* flags for new syscalls. > > > > > > > > > On Fri, Feb 28, 2020 at 02:53:32PM +0000, David Howells wrote: > > > >> > > > >> I've been told that RESOLVE_* flags, which can be found in linux/openat2.h, > > > >> should be used instead of the equivalent AT_* flags for new system calls. Is > > > >> this the case? > > > > > > > > Imho, it would make sense to use RESOLVE_* flags for new system calls > > > > and afair this was the original intention. > > > > The alternative is that RESOLVE_* flags are special to openat2(). But > > > > that seems strange, imho. The semantics openat2() has might be very > > > > useful for new system calls as well which might also want to support > > > > parts of AT_* flags (see fsinfo()). So we either end up adding new AT_* > > > > flags mirroring the new RESOLVE_* flags or we end up adding new > > > > RESOLVE_* flags mirroring parts of AT_* flags. And if that's a > > > > possibility I vote for RESOLVE_* flags going forward. The have better > > > > naming too imho. > > > > > > > > An argument against this could be that we might end up causing more > > > > confusion for userspace due to yet another set of flags. But maybe this > > > > isn't an issue as long as we restrict RESOLVE_* flags to new syscalls. > > > > When we introduce a new syscall userspace will have to add support for > > > > it anyway. > > > > > > I missed the start of the dicussion and what this is about, sorry. > > > > > > Regarding open flags, I think the key point for future APIs is to avoid > > > using the set of flags for both control of the operation itself > > > (O_NOFOLLOW/AT_SYMLINK_NOFOLLOW, O_NOCTTY) and properaties of the > > > resulting descriptor (O_RDWR, O_SYNC). I expect that doing that would > > Yeah, we have touched on that already and we have other APIs having > related problems. A clean way to avoid this problem is to require new > syscalls to either have two flag arguments, or - if appropriate - > suggest they make use of struct open_how that was implemented for > openat2(). By the way, if we really means business wrt to: separate resolution from fd-property falgs then shouldn't we either require O_NOFOLLOW for openat2() be specified in open_how->resolve or disallow O_NOFOLLOW for openat2() and introduce a new RESOLVE_* variant? Christian