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: Wed, 16 Aug 2017 19:06:02 +0300 Message-ID: <83o9rffqfp.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> <83zib0g221.fsf@gnu.org> <2bb4b7ee-6bf9-df3d-5cd8-ae7992b9f2e7@cs.ucla.edu> <83wp64fdc4.fsf@gnu.org> <83valnfv9u.fsf@gnu.org> <7f0c12f6-57eb-63b9-c296-e062cbf0710c@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1502899957 23207 195.159.176.226 (16 Aug 2017 16:12:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 16 Aug 2017 16:12:37 +0000 (UTC) Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org To: Paul Eggert , Richard Stallman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 16 18:12:30 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 1di0vf-0005Gb-LV for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Aug 2017 18:12:23 +0200 Original-Received: from localhost ([::1]:57293 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1di0vl-0005ZY-Vj for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Aug 2017 12:12:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1di0qZ-000154-0l for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 12:07:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1di0qU-0006mX-FI for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 12:07:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60933) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1di0qU-0006mS-BJ for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 12:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1di0qU-0008Qd-2n for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 12:07: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: Wed, 16 Aug 2017 16:07: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.150289960332375 (code B ref 27986); Wed, 16 Aug 2017 16:07:02 +0000 Original-Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 16:06:43 +0000 Original-Received: from localhost ([127.0.0.1]:41381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di0qB-0008Q7-G4 for submit@debbugs.gnu.org; Wed, 16 Aug 2017 12:06:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di0qA-0008Pv-NS for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 12:06:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1di0pz-0006Qa-OR for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 12:06:37 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1di0pz-0006QL-Le; Wed, 16 Aug 2017 12:06:31 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2845 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1di0pp-0007Cd-21; Wed, 16 Aug 2017 12:06:21 -0400 In-reply-to: <7f0c12f6-57eb-63b9-c296-e062cbf0710c@cs.ucla.edu> (message from Paul Eggert on Wed, 16 Aug 2017 08:15:34 -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:135822 Archived-At: > Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org > From: Paul Eggert > 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.