Re: [BUG] rename() from outside of the target dir breaks /proc exe symlink.

From: Piotr Karbowski
Date: Fri Jan 16 2015 - 13:26:08 EST


On 12/30/2014 11:40 PM, Piotr Karbowski wrote:
Hi Al,

On 12/27/2014 07:14 PM, Al Viro wrote:
That's because it never _had_ worked. Note that opening the damn thing
will give the right file - it does not work by traversing the result of
readlink(2). readlink(2) output on those is not promised to be useful
in all cases; often enough it is, but it won't work on cross-directory
renames, it can't be used to tell a filename that really ends with "
(deleted)"
from a removed file, etc. Moreover, it only very recently became
usable for
victim names with the last component longer than 40 characters if you
did an
overwriting rename.

What are you trying to use it for?

I am using it to track the origin of running processes. I am working
with continuous integration of a Linux embedded software. The tests goes
in Linux containers, multiple instances of binary with the same name in
a single container/namespace, all with cwd symlink pointing to / which
looks from outside virtually the same, the binaries are modified at
runtime by coping, modifing and replacing for another execution of the
same binary (using patchelf to add additional NEEDED to header or change
rpath or dynamic loader and such).

In my very usecase, the exe symlink is essential.

*Friendly bump*

Can anything be done about it or is there any other mechanism that I could use to get origin of the running binary?

-- Piotr.

--
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/