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

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

Eli Zaretskii wrote:

> Did you look at all the users of these functions in
> our codebase?

I have not looked at every single one in detail. I've looked at a fair sample. 
See below for more discussion.

> E.g., I see at least one use of rename-file in Gnus
> that moves a directory, possibly 2 such uses.

Moving a directory is not a problem. The only problem is when the destination is 
a directory but not a directory name and the intent is to change an entry in 
that directory rather than to change the original destination.

I agree that some uses in code will need to be adjusted. Most won't, though. For 
example, in the first occurrence of the string "rename-file" in Gnus, where 
gnus-agent-rename-group calls (gnus-rename-file old-path new-path t), the intent 
is to rename OLD-PATH to NEW-PATH, not to rename it to be an subsidiary entry to 
NEW-PATH. For this particular example, the proposed change is slightly 
beneficial, since it prevents rename-file from doing the wrong thing in the 
(admittedly unlikely) event that some other process changes NEW-PATH to a 
directory while Gnus is operating.

> What's more, some of the use cases will not even
> signal an error after the change, they will instead silently do
> something different from the previous versions, which is really bad.

This should be quite rare. The only scenario I see matching your concern is if 
the source is a directory, the destination is not a directory name but is an 
empty directory and is not a symlink, and the destination is not a descendant of 
the source. Although not impossible, this will happen so rarely that it doesn't 
invalidate the proposed change.

> At the very least, all the users in Emacs
> should be audited and fixed as needed.

Sure, I'll volunteer to do that. There are only 172 lines containing the string 
"rename-file" in our Emacs Lisp code base, for example, and it shouldn't be that 
much work to check them.

I've looked at this issue fairly carefully, and I'm afraid the solution I've 
proposed is the best way forward if we want to close the security hole in Emacs.