From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation Date: Tue, 15 Aug 2017 20:42:46 +0300 Message-ID: <83zib0g221.fsf@gnu.org> References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <1002ee73-0ab5-409b-831f-0c283c322264@cs.ucla.edu> <83o9rignt6.fsf@gnu.org> <83d17whl72.fsf@gnu.org> <8e6de468-600c-4f2d-a21a-c2ff3a63d065@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1502819053 2855 195.159.176.226 (15 Aug 2017 17:44:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 15 Aug 2017 17:44:13 +0000 (UTC) Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 15 19:44:09 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhfsr-0000I5-Sv for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Aug 2017 19:44:05 +0200 Original-Received: from localhost ([::1]:51647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhfsy-0008Bg-Al for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Aug 2017 13:44:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhfsr-0008At-P6 for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2017 13:44:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhfso-0005zy-K6 for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2017 13:44:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58352) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dhfso-0005zq-GE for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2017 13:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dhfso-0008K6-6t for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2017 13:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Aug 2017 17:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27986 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 27986-submit@debbugs.gnu.org id=B27986.150281898931968 (code B ref 27986); Tue, 15 Aug 2017 17:44:02 +0000 Original-Received: (at 27986) by debbugs.gnu.org; 15 Aug 2017 17:43:09 +0000 Original-Received: from localhost ([127.0.0.1]:38796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhfrx-0008JY-GW for submit@debbugs.gnu.org; Tue, 15 Aug 2017 13:43:09 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhfrv-0008JQ-Fz for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 13:43:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhfrn-0005bw-3C for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 13:43:02 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhfrn-0005bq-03; Tue, 15 Aug 2017 13:42:59 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2177 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dhfrl-0001tE-KP; Tue, 15 Aug 2017 13:42:58 -0400 In-reply-to: <8e6de468-600c-4f2d-a21a-c2ff3a63d065@cs.ucla.edu> (message from Paul Eggert on Tue, 15 Aug 2017 10:24:03 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:135785 Archived-At: > Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 15 Aug 2017 10:24:03 -0700 > > > How about eating the cake and having it, too? We could refrain from > > testing whether B is a directory if either (1) B ends in a slash, or > > (2) rename_noreplace succeeds. > > That doesn't close the security hole, I'm afraid. For example, the attacker can > create a nonempty directory B How would they know to create B before Emacs issues any system call that uses B? And how is this case different from the case that Emacs calls (rename-file A B) thinking B doesn't exist (e.g., because some prior code tested that)? Anyway, I firmly believe we should be backward compatible as a fallback. It is okay for the fallback to be insecure, as the current code is also insecure. But I don't think we should fail use cases that previously were legitimate, for many years. If my proposal is not workable, we should come up with something that is. > > What I don't quite understand is what will happen under your proposal > > to the calls of the form (rename-file A B) where B names an existing > > directory and doesn't end in slash? Will it fail, sometimes or > > always? > > On POSIX systems rename-file will fail if B is a nonempty directory, and will > succeed if B names an empty directory (this is all assuming B is not itself a > directory name). Ideally MS-Windows would be compatible; if not, we'd have to > document the incompatibility. I see no problems in being compatible in this sense. But wiping out the empty directory instead of moving the first argument into it is an incompatible change, and we should avoid that. > Thanks, good point, I plan to update the proposed patch accordingly and to > follow up soon. Please say in the manual explicitly that what you call "directory name" should end in a slash. Yes, I know this is already described elsewhere in the manual, but since this is important in this case, it doesn't hurt repeating it. It's especially important in the doc string and in lispref manual, since there the slash must be explicit, whereas in the interactive usage I believe RET might complete the slash.