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

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

Eli Zaretskii wrote:

> Knowing how Emacs works is not enough: they need to actually know the
> name of the directory to create,

By "knowing how Emacs works" I meant all of Emacs, including the Lisp program 
that it is running. We cannot rely on security-via-obscurity; we must assume 
that the attackers know not only the Emacs C source code, but the Lisp code that 
Emacs runs. Such an attacker will know the name of the directory to create.

>>> 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.
> 
> No, it's the same use case.  In both of them the attacker creates a
> directory ahead of Emacs using it in some system call.

Sure, but in the use case I'm talking about, the attacker can trash the victim's 
directory even though it's write-protected. In the case you're talking about, 
the attacker can't do anything other than what the attacker could do already.

>> 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.
> 
> If no other solution is possible, maybe this is what we should do.  If
> we decide to go that way, we should also decide what to do with the
> interactive use of those functions: whether to call the old or the new
> variant, because we need to keep backward compatibility there as well.

I don't see why. If a user calls M-x copy-file interactively they'll get the old 
function; if they call M-x file-copy they'll get the new one. Admittedly there 
will be confusion (see below).

>> I suspect that this would be more disruptive overall than the proposed
>> change, though (albeit disruptive in a different way).
> 
> How so?

It'll be disruption caused by the extra complexity: pairs of functions that do 
nearly the same thing, with user confusion over which function to call, and 
people calling the wrong one. Tramp will need at least four new methods to 
support, probably more. The complexity and confusion will go on and on, and will 
cost more than will be saved by the backward compatibility. It would be worth 
all this trouble if people needed the old behavior, but they mostly do not.