GNU bug report logs - #27986
26.0.50; `rename-file' can rename files without confirmation

Previous Next

Full log

Message #31 received at 27986 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: p.stephani2 <at> gmail.com, 27986 <at> debbugs.gnu.org
Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without
 confirmation
Date: Mon, 14 Aug 2017 18:40:37 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Cc: Philipp <p.stephani2 <at> gmail.com>, 27986 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.