bug#27986: 26.0.50; 'rename-file' can rename files without confirmation

[Paul Eggert <eggert@cs.ucla.edu>]

Eli Zaretskii wrote:

> How would they know to create B before Emacs issues any system call
> that uses B?

Because the attackers know how Emacs work and are attempting to exploit its 
security hole.

> And how is this case different from the case that Emacs calls
> (rename-file A B) thinking B doesn't exist (e.g., because some prior
> code tested that)?

The case in question trashes a directory that the attacker lacks permission to. 
The case you're talking about does not: it merely causes rename-file to fail.

> we should be backward compatible as a fallback.

I don't see how this can work, if the fallback method relies on two system calls 
that can fall victim to a race. I tried pretty hard to come up with secure and 
backward-compatible approaches before proposing the change. I could not come up 
with any, and doubt whether anyone else could either.

Another possibility is to implement new functions (say: file-copy, file-rename, 
file-link, file-symlink, and directory-copy) that behave like the existing 
functions except without the security hole, modify callers to use these new 
functions, and then mark the existing functions as deprecated due to security 
concerns. I suspect that this would be more disruptive overall than the proposed 
change, though (albeit disruptive in a different way).