Re: [RFC][PATCH] rbind across namespaces

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

 



Miklos Szeredi wrote:
In what sense?  readlink of /proc/PID/fd/* will provide a pathname
relative to current's root: useless for any paths not in current's
namespace.


Not readlink, but actual dereference of link will give you exactly the
vfsmount/dentry the file was opened on.  If you want to bind/move
whatever on that mount, that's possible, even if it's a "detached
tree".

Removing proc_check_root essentially removes any protection that namespaces provided in the first place.

Think of it like virtual memory. You can fork off and create your own COW instance, and no one can see what you are doing unless they ptrace you or explicitly ask you. The mountfd model allows for explicit handing off of vfsmounts between namespaces without allowing arbitrary access.


Note: I didn't say we should remove proc_check_root().  I said _if_
you remove it, _then_ mounting on foreign namespace will work, which
has actually been confirmed experimentally.


OK.

So your follow_link argument doesn't hold.  The proc code does the
follow_link in some clever way, that the looked up object will end up
with the same vfsmount/dentry pair as the file.


Yes. I hadn't realized that the only safe-guard in place was proc_check_root. I had made the assumption that follow_link was using vfs_follow_link with the readlink info.


Yet even this doesn't allow userspace to define it's own policy for inter-namespace manipulation.


OK.  Let's keep the kernel policy simple: just allow a process to
access it's _own_ file descriptors in proc.  I.e. allow access to
/proc/self/fd/* even if it comes from a foreign namespace.

Then the policy (who passes whom the file descriptors) is entirely up
to userspace (just as with your scheme).

/proc/self/fd/FD doesn't give any extra rights to the process, it just
makes mounting from/to detached mounts, and foreign namespaces
possible without new interfaces.

So you'd say 'mount /dev/foo /proc/self/fd/4' if 4 was an fd pointing to a directory in another namespace?

That does require proc_check_root be removed.  :\



Beware that due to the detached-subtrees bit, the locking became a bit ugly, requiring a global rw_lock for mntget/mntput. I still haven't figured out a better way to keep per-vfsmounts counts and per-subtree counts in sync.


Did you measure the effect on performace?  Maybe it isn't so bad.

As far as I could tell without doing high-smp benchmarks, it doesn't slow anything down. In this case, we aren't on the fastest path anyway, as we are usually

a) walking a path across a mountpoint, requiring the global vfsmount_lock anyway.
b) closing a file, which isn't fast either.

You could micro-optimize the pivoting of from one vfsmount to another during a walk to only grab the lock once, but there may be no profound effect and any gains would be lost in the noise.

Mike Waychison
-
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]
  Powered by Linux