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

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

[Piotr Karbowski]

Hi,

There's something wrong about exe symlink that can be found insde 
/proc/<pid>/ directories. When the running binary is replaced with 
another, using rename() call, the symlink may point to wrong path.

As example let me use sshd. I have running sshd from /usr/sbin. If I 
replace /usr/sbin/sshd one could expect to see exe symlink pointing to 
'/usr/sbin/sshd (deleted)', it does work this way if the source of 
rename() was in the same directory or nested within, thus rename like:

rename("/usr/sbin/foo", "/usr/sbin/sshd")

and

rename("/usr/sbin/bar/sshd", "/usr/sbin/sshd")

ends with a proper '/usr/sbin/sshd (deleted)' symlink.

if however the source was outside of the target directory, the symlink 
will point to the source path of rename() calls with 'deleted' sufix.

Here's example:

sbin # for i in `pidof sshd`; do ls -l /proc/$i/exe; done
lrwxrwxrwx 1 root root 0 Dec 27 18:09 /proc/29047/exe -> /usr/sbin/sshd

sbin # cp sshd /root/foo

sbin # strace -f perl -e 'rename("/root/foo", "/usr/sbin/sshd")' 2>&1 | 
grep sshd
rename("/root/foo", "/usr/sbin/sshd")   = 0

sbin # for i in `pidof sshd`; do ls -l /proc/$i/exe; done
lrwxrwxrwx 1 root root 0 Dec 27 18:09 /proc/29047/exe -> /root/sshd 
(deleted)

I am unable to find kernel version where it worked as one could presume 
thus I cannot offer to bisect commits to find the bad one.

The environment was kernel 3.17.4 x86_64 and the filesystem ext4.

-- Piotr.

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

[Al Viro]

On Sat, Dec 27, 2014 at 06:39:54PM +0100, Piotr Karbowski wrote:
> Hi,
> 
> There's something wrong about exe symlink that can be found insde
> /proc/<pid>/ directories. When the running binary is replaced with
> another, using rename() call, the symlink may point to wrong path.
> 
> As example let me use sshd. I have running sshd from /usr/sbin. If I
> replace /usr/sbin/sshd one could expect to see exe symlink pointing
> to '/usr/sbin/sshd (deleted)', it does work this way if the source
> of rename() was in the same directory or nested within, thus rename
> like:
> 
> rename("/usr/sbin/foo", "/usr/sbin/sshd")
> 
> and
> 
> rename("/usr/sbin/bar/sshd", "/usr/sbin/sshd")
> 
> ends with a proper '/usr/sbin/sshd (deleted)' symlink.
> 
> if however the source was outside of the target directory, the
> symlink will point to the source path of rename() calls with
> 'deleted' sufix.
> 
> Here's example:
> 
> sbin # for i in `pidof sshd`; do ls -l /proc/$i/exe; done
> lrwxrwxrwx 1 root root 0 Dec 27 18:09 /proc/29047/exe -> /usr/sbin/sshd
> 
> sbin # cp sshd /root/foo
> 
> sbin # strace -f perl -e 'rename("/root/foo", "/usr/sbin/sshd")'
> 2>&1 | grep sshd
> rename("/root/foo", "/usr/sbin/sshd")   = 0
> 
> sbin # for i in `pidof sshd`; do ls -l /proc/$i/exe; done
> lrwxrwxrwx 1 root root 0 Dec 27 18:09 /proc/29047/exe -> /root/sshd
> (deleted)
> 
> I am unable to find kernel version where it worked as one could
> presume thus I cannot offer to bisect commits to find the bad one.

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?

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

[Piotr Karbowski]

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.

-- Piotr.

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

[Piotr Karbowski]

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.

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

[Piotr Karbowski]

On 01/16/2015 07:25 PM, Piotr Karbowski wrote:
> 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?

*Even friendlier bump*

-- Piotr.