All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: ellie <el@horse64.org>
Cc: linux-man@vger.kernel.org, Petr Gajdos <pgajdos@suse.cz>
Subject: Re: Suggestion for clarifications on "man 5 proc" page regarding /proc/[pid]/self race conditions
Date: Wed, 13 Dec 2023 10:31:02 +0100	[thread overview]
Message-ID: <ZXl53MYCgFRMSYUG@debian> (raw)
In-Reply-To: <2c20d504-e6a4-476e-879f-be5618a4fd35@horse64.org>

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

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-12-13  9:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-12  8:47 Suggestion for clarifications on "man 5 proc" page regarding /proc/[pid]/self race conditions ellie
2023-12-12 14:17 ` Alejandro Colomar
2023-12-12 16:55   ` ellie
2023-12-12 17:39     ` Alejandro Colomar
2023-12-12 17:55       ` ellie
2023-12-13  9:31         ` Alejandro Colomar [this message]
2023-12-13  9:41           ` ellie
2023-12-13 13:54           ` Alejandro Colomar
2023-12-13 13:57             ` ellie
2024-06-07 22:23 ` ellie
2024-06-09 17:08   ` Alejandro Colomar
2024-06-09 17:28   ` Alejandro Colomar
2024-06-09 17:29   ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXl53MYCgFRMSYUG@debian \
    --to=alx@kernel.org \
    --cc=el@horse64.org \
    --cc=linux-man@vger.kernel.org \
    --cc=pgajdos@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.