[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