[lkml]   [2013]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 0/3] vfs: Detach mounts on unlink.
On 10/04/2013 05:41:25 PM, Eric W. Biederman wrote:
> This patchset is an attempt to address two problems:
> 1) Not all modifications to the filesystems happen through the vfs and
> since the vfs can not cope with a mount point being unlinked or
> renamed filesystems whose modifications that do not come through
> the
> vfs are required to lie.
> 2) Through an oversight it is now possible for one unprivileged user
> to
> mount something on another unprivileged users dentry and make it
> impossible for the other user to unlink or rename that dentry.
> It is now technically possible to easily lift the restriction on
> unlinking and renaming files with mount points on them, with a
> corresponding reduction in complexity of the vfs semantics and a small
> code side reduction.

A todo item I've had _forever_ is fixing chroot() to not be broken so
that you can trivially break out of a chroot via:


(Because chroot() affects where "/" points but NOT where "." points to,
and chdir does an == check with the dentry "/" points at to know when
to stop, so if you move "/" under "." you can back up to the actual
root of the tree.)

The above is why lxc uses pivot_root() instead of chroot().

These days, we have multiple mount trees so there's no reason chroot()
can't trim the process local mount tree (creating a new bind mount if
necessary). Except my todo list runneth over and I haven't had a chance
to dig in and see what would be involved. (Last time I brought this up
people were wondering why chroot() didn't just move "." to the new "/"
if it wasn't under it. I had no idea, still don't.)


 \ /
  Last update: 2013-10-06 01:21    [W:0.466 / U:4.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site