(Sorry for replying in two parts, I missed this in the first reading)
> >>walking mountpoints in userspace:
> >>http://marc.theaimsgroup.com/?l=linux-kernel&m=109875012510262&w=2
> >
> >
> > Is this needed? Userspace can find out mountpoints from /proc/mounts
> > (or something similar for detached trees).
> >
>
> With detached mountpoints (and especially with detached mountpoint
> _trees_) it can become very difficult to assess which trees are which.
>
> Also, just like /proc/PID/fd/*, /proc/mounts is built according to
> _current_'s root. This only gives a skewed view of what is going on.
I'm thinking of /proc/PID/fdinfo/FD/mounts or similar.
> >>attaching mountpoints in userspace:
> >>http://marc.theaimsgroup.com/?l=linux-fsdevel&m=109875063100111&w=2
> >
> >
> > Again, bind from/to /proc/PID/fd/FD should work without any new
> > interfaces.
>
> No.. It wouldn't. Pathname resolution is doing everything according to
> the ->readlink information provided by this magic proc files, again in
> current's namespace. If you care to hijack ->follow_link, prepare
> yourself for a slew of corner cases.
No need to hijack, it's already done. Removing calls to
proc_check_root() will allow access to different namespaces detached
mounts, etc. It's been tried and actually works.
What's more you don't even need /proc, just pass a file descriptor
(with reference to mount in different namespace, etc.) to another
process with SCM_RIGHTS, do fchrdir(fd), and then do mount --bind,
etc. This actually works with an unmodified kernel.
> >>detaching mountpoints in userspace:
> >>http://marc.theaimsgroup.com/?l=linux-kernel&m=109880051800963&w=2
> >
> >
> > What's wrong with sys_umount()?
>
> sys_umount only works with paths in current's namespace. It doesn't
> allow you to handle vfsmounts as primaries in userspace.
But it does. Again, either with fchdir() or /proc.
fchdir() has the drawback of only working on directories, and that a
process has only one CWD. The /proc approach has no such limitations.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
