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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 981B3C6FD18 for ; Wed, 19 Apr 2023 01:15:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230514AbjDSBPm (ORCPT ); Tue, 18 Apr 2023 21:15:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230033AbjDSBPl (ORCPT ); Tue, 18 Apr 2023 21:15:41 -0400 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D9B25E4D for ; Tue, 18 Apr 2023 18:15:35 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id v3so3305751wml.0 for ; Tue, 18 Apr 2023 18:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems.com; s=google; t=1681866934; x=1684458934; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/CR1IHc9HYlrEY3U89v5t/OX9dshkbM7G0EYz0O4fCI=; b=DrQpXoa2vwYv5KgKUocv5hzJ7n0BoWaqg2iruABRxMov33aWAqj4qiPvOpss7HZR6Y eyhIIAvceuyg0ifTvZI9Cnjr9QhSmbFFlN/3wGztQxQNtOJXXg+UDScf7cszt/Z4gG/8 8VrBJobMhaHoDO15M4c6DyBgLQEPPJ/FFkqH5cILQS0bDRRYYDDLrPUToOl7fvKCTc31 n30oW0IbuLxNMSx+pt1G042pQtt0qZ/C6hzA+axA6jk/GuLAvkMW+II58uvrZLMA9bWR JqjZobprhwD2ArHbL08QY90pWDqrTPn6wy6+nyAJ7Fzu9gPSCvgG92Pjz/yoAOITQeqq B/HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681866934; x=1684458934; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/CR1IHc9HYlrEY3U89v5t/OX9dshkbM7G0EYz0O4fCI=; b=cqiehMKQ2mJsgal5MR841C39r6G0DxfK4uSmogUdujpPnxP2twxhKuLAS+yNgfqpIh KefAZScWarQNckEPejs3NZMmLh1DUxLnK3P0qfJuoWEo32zkSMMFlLcOfyM3J2HxJ2Yr 1QH+HC/R7NxfS4a+EkgtbhE9m9yQN+yFrYB07/q7T8RKIWA/8AcO/h1ouGFYbWQnSlNQ 6oTLNPdawn+B4ndHeXdPK5YgqkMXGBx1kBNCDUyRn0GM0YaOovwPDsK2/hX2koQ0gjZP oP7Xvi/rFLrB6KJxAiiDu77nNANg26Ec62nrrQ9wAPsb+L9jPhKzSLAnV3dxCqD402T9 /DdQ== X-Gm-Message-State: AAQBX9ekI/gaUI9Ub5Uzjq8ZAxtgsryxfQSXSCHuGnHOOPYOlm4EamRG OLBr4xupiuGkNcA2cVF8a5a2IQ== X-Google-Smtp-Source: AKy350ZZSF1q/Toh4q2I8/pCwearcYtGy2vLmaJlZhVGcoLdCGT35UiwGZj6mJP4LqHxbBkciQlPeQ== X-Received: by 2002:a1c:f315:0:b0:3f1:6757:6245 with SMTP id q21-20020a1cf315000000b003f167576245mr10165291wmq.7.1681866934353; Tue, 18 Apr 2023 18:15:34 -0700 (PDT) Received: from hamza-pc ([2400:adc1:158:c700:9f4d:2f2e:ebe7:1578]) by smtp.gmail.com with ESMTPSA id o2-20020a05600c4fc200b003f1738e64c0sm514527wmq.20.2023.04.18.18.15.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Apr 2023 18:15:33 -0700 (PDT) Date: Wed, 19 Apr 2023 06:15:29 +0500 From: Ameer Hamza To: Christian Brauner Cc: viro@zeniv.linux.org.uk, jlayton@kernel.org, chuck.lever@oracle.com, arnd@arndb.de, guoren@kernel.org, palmer@rivosinc.com, f.fainelli@gmail.com, slark_xiao@163.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, awalker@ixsystems.com Subject: Re: [PATCH] Add new open(2) flag - O_EMPTY_PATH Message-ID: References: <20221228160249.428399-1-ahamza@ixsystems.com> <20230106130651.vxz7pjtu5gvchdgt@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230106130651.vxz7pjtu5gvchdgt@wittgenstein> Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Fri, Jan 06, 2023 at 02:06:51PM +0100, Christian Brauner wrote: > On Wed, Dec 28, 2022 at 09:02:49PM +0500, Ameer Hamza wrote: > > This patch adds a new flag O_EMPTY_PATH that allows openat and open > > system calls to open a file referenced by fd if the path is empty, > > and it is very similar to the FreeBSD O_EMPTY_PATH flag. This can be > > beneficial in some cases since it would avoid having to grant /proc > > access to things like samba containers for reopening files to change > > flags in a race-free way. > > > > Signed-off-by: Ameer Hamza > > --- > > In general this isn't a bad idea and Aleksa and I proposed this as part > of the openat2() patchset (see [1]). > > However, the reason we didn't do this right away was that we concluded > that it shouldn't be simply adding a flag. Reopening file descriptors > through procfs is indeed very useful and is often required. But it's > also been an endless source of subtle bugs and security holes as it > allows reopening file descriptors with more permissions than the > original file descriptor had. > > The same lax behavior should not be encoded into O_EMPTYPATH. Ideally we > would teach O_EMPTYPATH to adhere to magic link modes by default. This > would be tied to the idea of upgrade mask in openat2() (cf. [2]). They > allow a caller to specify the permissions that a file descriptor may be > reopened with at the time the fd is opened. > > [1]: https://lore.kernel.org/lkml/20190930183316.10190-4-cyphar@cyphar.com/ > [2]: https://lore.kernel.org/all/20220526130355.fo6gzbst455fxywy@senku/Kk Thank you for the detailed explanation and sorry for getting back late at it. It seems like a pre-requisite for O_EMPTYPATH is to make it safe and that depends on a patchset that Aleksa was working on. It would be helpful to know the current status of that effort and if we could expect it in the near future. The repo[1] that was mentioned here[2] seems to be private. I am wondering if there's a way to look at the patch somehow. [1]: https://github.com/cyphar/linux/tree/magiclink/main [2]: https://lore.kernel.org/all/20220526130952.z5efngrnh7xtli32@senku/