On 2026-03-08 23:46, Ajay S.K wrote:
The situation does not depend on creating /tmp/nmap during mv. The behavior
occurs earlier during the cp operation when the destination file already exists
and is controlled by an unprivileged user.
Ah, I was confused by your earlier email which talked about the attacker
running simultaneously with the mv.
To avoid the race you mention, use the following cp command instead:
cp -a --update=none-fail /usr/bin/nmap /tmp/nmap
--update=none-fail is not the default, for compatibility with
longstanding practice and with POSIX. But it sounds like you need it.
