Re: Suggestion for clarifications on "man 5 proc" page regarding /proc/[pid]/self race conditions

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]

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

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]