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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 445C6C433DF for ; Wed, 12 Aug 2020 17:16:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D87FD20771 for ; Wed, 12 Aug 2020 17:16:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=szeredi.hu header.i=@szeredi.hu header.b="nAulnfLe" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726578AbgHLRQv (ORCPT ); Wed, 12 Aug 2020 13:16:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726456AbgHLRQu (ORCPT ); Wed, 12 Aug 2020 13:16:50 -0400 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26077C061386 for ; Wed, 12 Aug 2020 10:16:50 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id l23so2099916edv.11 for ; Wed, 12 Aug 2020 10:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l2X1UTNYtxtD9AqiCPxyGHdXjAbLFgoKechHodwc0Uo=; b=nAulnfLe5uw3GGbI4m3Tum5zj3laHAl5lzMTlbg9w0RQxUXyfMRVW0PUksH7Rp6ZFN Yq1nSYnweoNegqNGWk3syhijVezp9QgoP5+S2Di2gSfqAOOXVBABYvP7X+VVxFs5wL3L ah3L2fnd4E2PFbne2qLQvAQDr2nPtHrCw32E8= 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=l2X1UTNYtxtD9AqiCPxyGHdXjAbLFgoKechHodwc0Uo=; b=UM5NCijQrxWX7cjGYhjKw/hgluAQClXVOTEFrwRqim3fjxPugvkfMNtliTC2jjBd03 bzfXbYZ0nSq1QI7bTfcBONGKA3TFuR4uOSNelMKnyz28TgO0g6P54JfGBqg9mGNfVrQi g08J0rX1jtVrbDY5/zOD3FH58p//JPVa8bhc+xWSI5zwUA9jk6j9Ug3dhvOdFKyBrt1J yTCdkZpyHZS/hXlRqyZZvt1aa81P/3Hsfh6AkmHPcPgZH978LgYVDiFMgcCC2/VtK+uo nAnXZEdMMUfHzanUTRLJ0QK3TFToEnBhLGapYCBILErdYJZF67gLuFqOHbDxRx0EXolN F22g== X-Gm-Message-State: AOAM5313qtZQC3ziYhN6jHEBYIVxuYMOeDhViB4hSUhJf0Mv6/zCciIS 26QW1hEhr9wqKKHc9oQz1uH/qBMJ0tf6GQAxmKpQgA== X-Google-Smtp-Source: ABdhPJxug2NLkyVDrt4SDzElrjaxLcJAHADPULDoz4hIsy0nzQPyH+wfb4erX3M7q+SBR4y2ScqFzLhktBpqx/PV0jA= X-Received: by 2002:a05:6402:12c4:: with SMTP id k4mr905858edx.358.1597252608671; Wed, 12 Aug 2020 10:16:48 -0700 (PDT) MIME-Version: 1.0 References: <20200812143957.GQ1236603@ZenIV.linux.org.uk> <20200812150807.GR1236603@ZenIV.linux.org.uk> <20200812163347.GS1236603@ZenIV.linux.org.uk> In-Reply-To: <20200812163347.GS1236603@ZenIV.linux.org.uk> From: Miklos Szeredi Date: Wed, 12 Aug 2020 19:16:37 +0200 Message-ID: Subject: Re: file metadata via fs API (was: [GIT PULL] Filesystem Information) To: Al Viro Cc: Linus Torvalds , Jann Horn , Casey Schaufler , Andy Lutomirski , linux-fsdevel , David Howells , Karel Zak , Jeff Layton , Miklos Szeredi , Nicolas Dichtel , Christian Brauner , Lennart Poettering , Linux API , Ian Kent , LSM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Wed, Aug 12, 2020 at 6:33 PM Al Viro wrote: > > On Wed, Aug 12, 2020 at 05:13:14PM +0200, Miklos Szeredi wrote: > > Why does it have to have a struct mount? It does not have to use > > dentry/mount based path lookup. > > What the fuck? So we suddenly get an additional class of objects > serving as kinda-sorta analogues of dentries *AND* now struct file > might refer to that instead of a dentry/mount pair - all on the VFS > level? And so do all the syscalls you want to allow for such "pathnames"? The only syscall I'd want to allow is open, everything else would be on the open files themselves. file->f_path can refer to an anon mount/inode, the real object is referred to by file->private_data. The change to namei.c would be on the order of ~10 lines. No other parts of the VFS would be affected. Maybe I'm optimistic; we'll see... Now off to something completely different. Back on Tuesday. Thanks, Miklos