Yes, that makes sense. I suspect that you are correct. However, it would
be nice to have a definite confirmation by someone, hence also my
suggestion to address it in the man page.
I can make and send a patch suggestion (I hope I'll figure out the
correct format) in a few days with actual man page text changes under
the assumption that open("/proc/self/exe") is free of races, but I'm
probably not the person to actually verify that this assumption is correct.
On 12/13/23 2:54 PM, Alejandro Colomar wrote:
Hi ellie,
On Wed, Dec 13, 2023 at 10:31:02AM +0100, Alejandro Colomar wrote:
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;
On 12/13/23 10:31 AM, Alejandro Colomar wrote:
There don't seem to be any
races in open("/proc/[pid]/exe", ...).
ellie wrote:
| Sorry if I'm just confused, but I don't understand how the given test
| script reproduces or tests anything relevant to a potential open() race.
|
| The race would work like this:
|
| 1. Process A issues open("/proc/self/exe")
|
| 2. Process A's open() on /proc/self/exe heads into whatever libc or
| kernel path that resolves where that symlink points to a path, if it's
| treated as one.
|
| 3. Process scheduler switches to process B.
|
| 4. Process B switches out process A's binary, such that a different
| binary is now at the old path.
|
| 5. Process A's open() code in libc or kernel space resumes and opens the
| file pointed to by the given path, which is now a new binary.
|
| I'm pretty sure you can't test that anyway to rule it out, that could
| only be answered by looking at all the relevant code and whether
| /proc/self/exe is ever resolved to a path (like I assume an actual
| symlink usually is) or directly to an inode (which would likely be safe).
I didn't test exactly that, but I proved that it doesn't work like a
symlink. If it were a simple symlink, my script wouldn't get the new
path of the file after moving or removing it, and the symlink would
become dangling.
Still, the kernel could do the stupid thing: magically update the
symlink when the file changes, but still use a symlink, so open(2) would
still have a race. I'm assuming the kernel doesn't do that stupid thing.
It must be implemented using the file description, or something like
that, and thus it would be free of races.
Have a lovely day,
Alex
