[LSF/MM TOPIC] VFS rename fences/zones/whatuwanacallit

[LSF/MM TOPIC] VFS rename fences/zones/whatuwanacallit

[Amir Goldstein]

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.

Re: [LSF/MM TOPIC] VFS rename fences/zones/whatuwanacallit

[Al Viro]

On Fri, Feb 22, 2019 at 09:08:24AM +0200, Amir Goldstein wrote:
> 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.

'scalled "mount"...  That's precisely the reason why cross-device
operations prevention is "different mounts", not just "different
superblocks".  Why bother doing that on dentry level?

Re: [LSF/MM TOPIC] VFS rename fences/zones/whatuwanacallit

[Amir Goldstein]

On Fri, Feb 22, 2019 at 9:17 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Fri, Feb 22, 2019 at 09:08:24AM +0200, Amir Goldstein wrote:
> > 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.
>
> 'scalled "mount"...  That's precisely the reason why cross-device
> operations prevention is "different mounts", not just "different
> superblocks".  Why bother doing that on dentry level?

Several reasons.

For circumventing attack vectors (i.e. overlayfs and shiftfs) mounts
are not a "strong" enough jail. I don't think I need to explain why.
In any case, I am thinking of kernel attack vectors from mounting
stacked filesytems and messing with their weaknesses in dealing
with corner cases.

One other reason goes back to you.
In the past, you objected to propagating path/mnt into fsnotify vfs hooks,
so my way forward with fsnotify subtree watch is introducing some sort
of subtree concept to dentry level.

I think people that want subtree level watches normally can live with
that subtree becoming a jail for inodes. As a general rule, containers
that use same sb for many instances for storage (i.e. overlayfs shiftfs)
would want that sort of jail.

Thanks,
Amir.