From: Amir Goldstein <firstname.lastname@example.org> To: email@example.com Cc: linux-fsdevel <firstname.lastname@example.org>, Jan Kara <email@example.com>, Miklos Szeredi <firstname.lastname@example.org>, Linux Containers <email@example.com>, James Bottomley <James.Bottomley@hansenpartnership.com>, Seth Forshee <firstname.lastname@example.org>, Al Viro <email@example.com> Subject: [LSF/MM TOPIC] VFS rename fences/zones/whatuwanacallit Date: Fri, 22 Feb 2019 09:08:24 +0200 Message-ID: <CAOQ4uxhBVhyyJv0+xSFQiGQEj60AbD3SADfKK40uAiC4GF2p9Q@mail.gmail.com> (raw) 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.
next reply index Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-22 7:08 Amir Goldstein [this message] 2019-02-22 7:17 ` Al Viro 2019-02-22 7:34 ` Amir Goldstein
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAOQ4uxhBVhyyJv0+xSFQiGQEj60AbD3SADfKK40uAiC4GF2p9Q@mail.gmail.com \ --firstname.lastname@example.org \ --cc=James.Bottomley@hansenpartnership.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Fsdevel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \ firstname.lastname@example.org public-inbox-index linux-fsdevel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git