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

[Eli Zaretskii]

> Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 15 Aug 2017 22:06:38 -0700
> 
>     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.

It is reasonable to assume that the attacker has access to the Emacs
sources, and so knows what Emacs will do in any specific situation,
given enough information about the files and directories involved in
the particular use case.  But it is not necessarily reasonable to
assume the attacker knows exactly what Emacs is doing at this very
moment, and what files/directories it will be accessing in the very
near future, without any evidence from the system calls emitted by
Emacs and/or the changes to the filesystem it made in the recent past.
You are describing a situation where the attacker somehow knows what
file/directory will be accessed _ahead_ of Emacs actually accessing
it.  This _might_ be somehow possible when Emacs runs
non-interactively, as part of some deterministic script, but not in
interactive usage, which is how Emacs is normally used.  So I don't
see how the attacker could do that in general, except by having full
control of the Emacs process, in the 'ptrace' sense or similar.  And
if the attacker has such a control, you cannot defend against it,
because it can simply call any Emacs functions with any arguments.

IOW I don't see any "security by obscurity" here, I see a case where
you assign super-natural abilities to attackers.

I think our security related scenario should start after the initial
call to rename_noreplace, and not before it, because before that call
there's no external evidence that Emacs is going to call rename-file,
and with what arguments.

>     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.

I thought you were proposing to redirect the interactive commands to
the new functions.  If that's not what you meant, then indeed there's
no such issue, but then obsoleting is out of the question, since we
cannot obsolete user commands.

> 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.

It's additional complexity, I agree.  But if people want secure code,
they _will_ use the more secure variants (which is why I think
rename-file-securely is a better name than file-rename, and similarly
for other functions).  It's basically the same situation as with, say,
strtok vs strtok_r, to take just one similar example.

Whether people want "M-x foo bar" produce bar/foo or just bar, is open
to argument.  My impression is that they want the former, because it
is what "mv foo bar" does by default when bar is a directory.  Note
that mv doesn't require a trailing slash in this case, and it gives
the user an explicit opt-in switch to change the behavior to the one
you proposed.  (We could provide such an optional argument as well, as
an alternative to introducing new functions.)