[lxc-users] Finding the physical path of a binary running in container

Serge Hallyn serge.hallyn at ubuntu.com
Thu Sep 4 18:10:04 UTC 2014


Quoting Aaron Lewis (the.warl0ck.1989 at gmail.com):
> Hi,
> 
> I have a program, say /usr/bin/nginx running in a container.
> Now on the host machine, when I check /proc/pid/exe it points to
> "/usr/bin/nginx" which is not the physical path
> 
> Is there any way to get the correct path?

Short answer, depends on how robust you want it to be.

Even shorter answer, there is no "correct path".

A few points,

1. you can look under /proc/pid/root/ to see the path
which is being talked about.

2. however that may have already been changed due to either
a 'rm /bin/ls; cp /bin/ls.new /bin/ls' or a unshare(CLONE_NEWNS)
by nginx.

3. I'm actually not sure whether, if you open /proc/self/exe,
if that will actually open the file that was executed regardless
of (2), or whether it will walk the path and open the new file.

4. The actual /proc/pid/root of the container is *not*
/var/lib/lxc/c1/rootfs, it's /usr/lib/x86_64-linux-gnu/lxc
onto which either /var/lib/lxc/c1/rootfs or some other rootfs
was mounted in a new namespace.  So really you have no definately
valid path to the binary.

5. subject to (2), you can also setns(2) to the /proc/pid/ns/mnt
of the container task and then open the path, as an alternative
to using /proc/pid/root.

Ideally what you'd have is a (device:inode_number) stored somewhere
under /proc/pid, but I don't see it.  It's also not as valuable as
you'd think, since /proc/pid/exe may have already been attacked with
a buffer overflow, mmap()d /bin/shadow and jumped into that memory,
i.e. not be running /proc/pid/exe at all any more.

-serge


More information about the lxc-users mailing list