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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 DCBA1C43381 for ; Fri, 22 Feb 2019 07:08:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A8BD7207E0 for ; Fri, 22 Feb 2019 07:08:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YTtx1qe0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725944AbfBVHIf (ORCPT ); Fri, 22 Feb 2019 02:08:35 -0500 Received: from mail-yb1-f193.google.com ([209.85.219.193]:45804 "EHLO mail-yb1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725821AbfBVHIf (ORCPT ); Fri, 22 Feb 2019 02:08:35 -0500 Received: by mail-yb1-f193.google.com with SMTP id n134so462399ybg.12 for ; Thu, 21 Feb 2019 23:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=urm4mDrtOVMJ6Jd/izuoQ/5v63vIZRZ2h/YqL2hdRZQ=; b=YTtx1qe01dQEVV5rFfpKz+M2getvD9ow/doCcrrD5HXvYzW8oW1OqpsSB822rY+xxP EBkAn8B13NSRD3spXGqiIUNq3Jc+54fM/8feZSzuuUJ2m5DAXqVNxhEfAiO4Sik7U0ih XD03/QQedoB+9l7wEkW1B9rxV7JNb6F5bQQ1yLI26R4oKeU78543w6K1wyiVL5z0lBRL 0F+rbmv/K/ro3VUNLsCSorahgZeU0BbERU0h3TPFUCjiCoKEUaDtl8OPiTY1M+51NR7S kh+K2tu5boirlss8t52JL/+qhPN/JD6oeLYk8SMpU4tEDbiRf6B4j8hCw/SRHnCxfpMK i3Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=urm4mDrtOVMJ6Jd/izuoQ/5v63vIZRZ2h/YqL2hdRZQ=; b=ayVLRQ125jH4w0B8VMPTKbEg13LRlWNpsw/HtCO02YxdSZw6eNw4wt2jrTP0D4CmN/ S29VCsn7hteZuvifbqJpoFYPFxA8BK9z7vpmknTMwp6scV/9HaBefQeP5noTg7uZn7gx fG1lZ8LWWdCjgmUE00Enm+udFj/GG1geVUlmZ6Q86wpSzj3eF1suXDwnHa49/qcNqP3h GGY5/Wpw4nrq1BT1TEmhvDr+QraNrzINX+zBUv719DT7aUrnImRDfSZMf2aVQO4K5Ycl tAEwVi3kJUcvw37chML2yhK76jLIzKURB7L2ZG0XPH3VV7wjyZn3oWowfs7izi3vjotw bxaA== X-Gm-Message-State: AHQUAuZZj116x1ylf5XePM4VuIX0CI5s0SjsyZP9w46Yez2Fw3A65DQX HXcS9Exq2T3kqFGlCjktX0H1p1SPap/5EI+YLtQ= X-Google-Smtp-Source: AHgI3IbSq4uetjy9GDcBU3F8BbS3tftOGtEVR1tspPw39MzWdEHB7Byo3PByol+tpK1GBTqUXj6U0AB3+37xp6O3QNE= X-Received: by 2002:a25:35d5:: with SMTP id c204mr2132649yba.325.1550819313913; Thu, 21 Feb 2019 23:08:33 -0800 (PST) MIME-Version: 1.0 From: Amir Goldstein Date: Fri, 22 Feb 2019 09:08:24 +0200 Message-ID: Subject: [LSF/MM TOPIC] VFS rename fences/zones/whatuwanacallit To: lsf-pc@lists.linux-foundation.org Cc: linux-fsdevel , Jan Kara , Miklos Szeredi , Linux Containers , James Bottomley , Seth Forshee , Al Viro Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Last minute proposal for fs track. This is something that's been on my mind for a while and I was wondering if others have interest in something like this. The idea is to declare a directory as a root of a subtree from which inodes cannot escape via rename/link. The implementation could rely on lock_rename() traversing ancestors under s_vfs_rename_mutex and not allowing to cross a rename fence. The easiest way to enforce same restriction for link() is to require lock_rename() for links. I am not sure if this would cause performance issues in any real workloads? The possible users for such a facility are: - Overlayfs declaring lower dir as rename fence as means to circumvent possible attack vectors - Shiftfs declaring mark point as rename fence as means to circumvent possible attack vectors - Basis for fsnotify subtree watch (*) (*) I have implemented super block watch and got lots of feedback from people waiting for this feature, but what they really want is usually subtree watch and maybe willing to settle for super block watch. subtree watch would also be useful for VFS level snapshots (a.k.a overlayfs snapshots). Project ids, implemented in xfs and ext4 already provide a somewhat similar functionality, mainly used to maintain quotas for subtrees, but files inside a subtrees are allowed to change project id, so its not the exact same thing and of course VFS has no knowledge of project ids. There is some unused space in directory dentry taken by the redundancy of the d_alias "list" that must contain a single inode, that could be used to describe the VFS fences/ zones topology. Thoughs? flames? Thanks, Amir.