Messages in this thread | | | Date | Sat, 05 Oct 2013 18:07:42 -0500 | From | Rob Landley <> | Subject | Re: [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:
chdir("/"); mkdir("sub"); chroot("sub"); chdir("./../../../../../../../..");
(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.)
Rob
| |