[CRIU] [PATCH 3/3] mount: open a root directory for mount namesapces via the root task

[Andrew Vagin]

On Wed, Aug 03, 2016 at 12:59:21PM +0300, Pavel Emelyanov wrote:
> On 08/02/2016 09:04 PM, Andrew Vagin wrote:
> > On Tue, Aug 02, 2016 at 03:08:17PM +0300, Pavel Emelyanov wrote:
> >> On 07/27/2016 09:21 PM, Andrey Vagin wrote:
> >>> From: Andrew Vagin <avagin at virtuozzo.com>
> >>>
> >>> We use openat() syscall to open files in various mount namespaces.
> >>> Recently we found that if a path contains absolute symlinks, openat()
> >>> syscall resolves them relative to the current root, but they has to be
> >>> resolved relative to the root of the target namespace, so we need to
> >>> change root before restoring a file descriprot.
> >>
> >> OK, what's the exact problem we're having now? Which openat() is called
> >> on a path with symlink?
> > 
> > When we restore a file, we use openat() to open it:
> > 
> > fd = openat(ns_root_fd, rfi->path, flags);
> > 
> > but rfi->path can containe absolute symlinks 
> 
> How can this happen? The rfi->path is the path we read from /proc/pid/fd/n
> which, in turn, is generated by kernel d_path() routine which, in turn :),
> walks the dentry tree upwards, so all symlinks in between are impossible!

Where were you before? There is no problem about files. But it exists
for unix sockets:

[root at fc24 ~]# lsof -p 17952 | grep xxx
python  17952 root    4u  unix 0xffff880036e23840       0t0  718377
/tmp/xxx/unix type=DGRAM
[root at fc24 ~]# ls -ld /tmp/xxx
lrwxrwxrwx 1 root root 8 Aug  3 18:57 /tmp/xxx -> /tmp/yyy

> 
> > and in this case, openat()
> > will be not enogh and we need to make chroot to resolve symlinks
> > correctly.
> > 
> > fchroot(ns_root_fd)
> > open(rfi->path, flags);
>