Re: [PATCH] private mounts
From: Ram
Date: Fri Apr 29 2005 - 02:58:47 EST
On Thu, 2005-04-28 at 15:08, Jamie Lokier wrote:
> Ram wrote:
> > > I've looked at the code. Look in fs/proc/base.c (Linux 2.6.10),
> > > proc_root_link().
> > >
> > > I don't see anything there to prevent you from traversing to the
> > > mounts in the other namespace.
> > >
> > > So why is it failing? Any idea?
> >
> > Since you are traversing a symlink, you will be traversing the symlink
> > in the context of traversing process's namespace.
> >
> > If process 'x' is traversing /proc/y/root , the lookup for the root
> > dentry will happen in the context of process x's namespace, and not
> > process y's namespace. Hence process 'x' wont really get into
> > the namespace of the process y.
>
> Lookups don't happen in the context of a namespace.
>
> They happen in the context of a vfsmnt. And the switch to a new
> vfsmnt is done by matching against (dentry,parent-vfsmnt) pairs.
> current->namespace is only checked for mount & unmount operations, not
> for path lookups.
Looked deeper into the code, and realized that in procfs, the symlink is
not followed through link_path_walk(). instead it is expected to
return the root vfsmount of the traversed process as you rightly
pointed.
>
> Which means proc_root_link, when it switches to the vfsmnt at the root
> of the other process, should traverse into the tree of vfsmnts which
> make up the other namespace.
Yes. But proc_check_root() in proc_pid_follow_link() is failing the
traversal, because it is expecting the root vfsmount of the traversed
process to belong to the vfsmount tree of the traversing process.
In other words its expecting them to be both in the same namespace.
The permissions get denied by this code in proc_check_root():
while (vfsmnt != our_vfsmnt) {
if (vfsmnt == vfsmnt->mnt_parent)
goto out;
de = vfsmnt->mnt_mountpoint;
vfsmnt = vfsmnt->mnt_parent;
}
RP
> -- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/