Hi ellie,
On Tue, Dec 12, 2023 at 06:55:22PM +0100, ellie wrote:
> Hi Alejandro,
>
> Thanks so much for elaborating! Just to clear it up, I hope it's obvious
> enough readlink("/proc/self/exe") to get a path, and then using open() on
> the result has a race by design: of the binary targeted by that path being
> renamed and replaced with a different one between the readlink and the open.
> Yet this approach seems to be commonly used, so a warning on the man page
> listing /proc/self/exe not to do that seems useful.
Would you mind sending a patch for that?
>
> Now whether open("/proc/self/exe") has the same race condition would likely
> deoend on what that does behind the scenes. If /proc/self/exe is internally
> resolved to a path string first and not directly to an inode, then it should
> suffer the same race condition but with a smaller time window. If instead
> the kernel implementation is smart enough to not actually handle it like a
> "true" symlink, but rather look up the inode associated with the process
> directly, it would likely be safe.
>
> Since I vaguely remember /proc/self/exe still working when the inode was
> deleted, I assume it's likely something smarter and might be race-condition
> safe when directly opened. But it would be nice to have some more definite
> info on that in the man page, just to be safe.
I'm going to guess a little bit, from the following script:
$ cat ppe.sh
#!/home/alx/tmp/bash
f="$(readlink /proc/$$/exe)";
set -x;
mv $f $f.bak;
cp /usr/bin/bash $f;
readlink /proc/$$/exe;
cp /usr/bin/bash $f.bak;
readlink /proc/$$/exe;
rm $f.bak;
readlink /proc/$$/exe;
echo malicious >$f.bak;
readlink /proc/$$/exe;
head -c4 /proc/$$/exe;
$ ./ppe.sh
+ mv /home/alx/tmp/bash /home/alx/tmp/bash.bak
+ cp /usr/bin/bash /home/alx/tmp/bash
+ readlink /proc/5055/exe
/home/alx/tmp/bash.bak
+ cp /usr/bin/bash /home/alx/tmp/bash.bak
cp: cannot create regular file '/home/alx/tmp/bash.bak': Text file busy
+ readlink /proc/5055/exe
/home/alx/tmp/bash.bak
+ rm /home/alx/tmp/bash.bak
+ readlink /proc/5055/exe
/home/alx/tmp/bash.bak (deleted)
+ echo malicious
+ readlink /proc/5055/exe
/home/alx/tmp/bash.bak (deleted)
+ head -c4 /proc/5055/exe
ELF
It doesn't seem to care about the text of the symlink, which in fact
changes as much as the file itself does. There don't seem to be any
races in open("/proc/[pid]/exe", ...).
>
> My apologies if I got some of the technical parts of this wrong, but
> hopefully it provides some explanation of why I brought this up.
Sure.
Have a nice day,
Alex
--
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.
Attachment:
signature.asc
Description: PGP signature
