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

[Eli Zaretskii <eliz@gnu.org>]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: Philipp <p.stephani2@gmail.com>, 27986@debbugs.gnu.org
> Date: Sun, 13 Aug 2017 15:42:05 -0700
> 
> Paul Eggert wrote:
> > there are races on GNU/Linux which can lead to potential security problems. 
> > Perhaps we can't fix these races on MS-Windows but we should be able to fix them 
> > on a GNUish host.

For the record: 'rename' is atomic on Windows when the target doesn't
exist.  It's the case when the target exists that cannot be guaranteed
to be handled atomically, AFAIU, because deleting the old target and
renaming are not necessarily an atomic operation on Windows.  I don't
know if this is an issue, since the current code in rename-file uses 2
separate system calls in this case anyway, even on Posix platforms.

> Attached is a proposed patch to fix this security problem. If I understand 
> things correctly, the fix should work on MS-Windows and on case-insensitive file 
> systems. Since this patch entails an incompatible change to the (undocumented) 
> behavior of (rename-file A B) when B is a directory but is not a directory name, 
> I'll mention the proposed change on emacs-devel.

I'm uneasy, to say the least, to change the semantic of such a veteran
behavior.  Could you please take a step back and elaborate on the
races and the security problems related to this, and why the change in
the semantics you propose is the solution?  I'd like to understand the
problem better before we decide on the solution.

Thanks.