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: Wed, 16 Aug 2017 08:15:34 -0700
> 
> I do take your point that interactive use is different. So, here is a 
> proposed 
> change to the patch: if the ok-is-already-exists flag is an integer (which 
> suggests interactive use), and if the destination is not a directory name 
> (trailing "/") but happens to be an existing directory, then Emacs asks the 
> user 
> if it is OK to rename to a subfile of the destination. This would allay most 
> the 
> security concerns that I have, and I hope it would address most of the 
> backward-compatibility concerns that you have.

I don't know...  Did you look at all the users of these functions in
our codebase?  E.g., I see at least one use of rename-file in Gnus
that moves a directory, possibly 2 such uses.  And I only looked at a
single function.  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.

We could be easily shooting ourselves in the foot with such
incompatible changes.  At the very least, all the users in Emacs
should be audited and fixed as needed.

What do others think?  Richard, Stefan, John?

> The situation with "mv" was different, as POSIX and longstanding 
> documentation 
> required the unsafe behavior and many scripts relied on it. In contrast, the 
> Emacs documentation is thoroughly muddled and contradictory in this area, and 
> code using rename-file etc. would more likely benefit from the proposed 
> change 
> (because of improved security) than be hurt by it (by loss of backward 
> compatibility with poorly-documented and insecure behavior).

My problem is not with being able to defend our change in a court of
law, my problem is with people's muscle memory and with existing code
that was working in certain ways since about forever.