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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 22, 2019 at 9:17 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux