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 17:21:33 +0300 Message-ID: <83valnfv9u.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1502893344 403 195.159.176.226 (16 Aug 2017 14:22:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 16 Aug 2017 14:22:24 +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 Wed Aug 16 16:22:14 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 1dhzCz-0007pb-MT for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Aug 2017 16:22:09 +0200 Original-Received: from localhost ([::1]:49745 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhzD6-0003MC-19 for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Aug 2017 10:22:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhzCw-0003LW-Jt for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 10:22:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhzCs-00050g-28 for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 10:22:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60787) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dhzCr-000501-V0 for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 10:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dhzCr-0000JD-MU for bug-gnu-emacs@gnu.org; Wed, 16 Aug 2017 10:22:01 -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 14:22:01 +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.15028933191178 (code B ref 27986); Wed, 16 Aug 2017 14:22:01 +0000 Original-Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 14:21:59 +0000 Original-Received: from localhost ([127.0.0.1]:41235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhzCp-0000Iw-9h for submit@debbugs.gnu.org; Wed, 16 Aug 2017 10:21:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhzCn-0000Ik-Ub for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 10:21:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhzCe-0004Qo-BS for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 10:21:52 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhzCe-0004Qe-8V; Wed, 16 Aug 2017 10:21:48 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2697 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dhzCd-0001Bu-Jm; Wed, 16 Aug 2017 10:21:48 -0400 In-reply-to: (message from Paul Eggert on Tue, 15 Aug 2017 22:06:38 -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:135812 Archived-At: > Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 15 Aug 2017 22:06:38 -0700 > > Knowing how Emacs works is not enough: they need to actually know the > name of the directory to create, > > By "knowing how Emacs works" I meant all of Emacs, including the Lisp program that it is running. We cannot rely on security-via-obscurity; we must assume that the attackers know not only the Emacs C source code, but the Lisp code that Emacs runs. Such an attacker will know the name of the directory to create. It is reasonable to assume that the attacker has access to the Emacs sources, and so knows what Emacs will do in any specific situation, given enough information about the files and directories involved in the particular use case. But it is not necessarily reasonable to assume the attacker knows exactly what Emacs is doing at this very moment, and what files/directories it will be accessing in the very near future, without any evidence from the system calls emitted by Emacs and/or the changes to the filesystem it made in the recent past. You are describing a situation where the attacker somehow knows what file/directory will be accessed _ahead_ of Emacs actually accessing it. This _might_ be somehow possible when Emacs runs non-interactively, as part of some deterministic script, but not in interactive usage, which is how Emacs is normally used. So I don't see how the attacker could do that in general, except by having full control of the Emacs process, in the 'ptrace' sense or similar. And if the attacker has such a control, you cannot defend against it, because it can simply call any Emacs functions with any arguments. IOW I don't see any "security by obscurity" here, I see a case where you assign super-natural abilities to attackers. I think our security related scenario should start after the initial call to rename_noreplace, and not before it, because before that call there's no external evidence that Emacs is going to call rename-file, and with what arguments. > If no other solution is possible, maybe this is what we should do. If > we decide to go that way, we should also decide what to do with the > interactive use of those functions: whether to call the old or the new > variant, because we need to keep backward compatibility there as well. > > I don't see why. If a user calls M-x copy-file interactively they'll > get the old function; if they call M-x file-copy they'll get the new > one. I thought you were proposing to redirect the interactive commands to the new functions. If that's not what you meant, then indeed there's no such issue, but then obsoleting is out of the question, since we cannot obsolete user commands. > It'll be disruption caused by the extra complexity: pairs of functions that do nearly the same thing, with user confusion over which function to call, and people calling the wrong one. Tramp will need at least four new methods to support, probably more. The complexity and confusion will go on and on, and will cost more than will be saved by the backward compatibility. It would be worth all this trouble if people needed the old behavior, but they mostly do not. It's additional complexity, I agree. But if people want secure code, they _will_ use the more secure variants (which is why I think rename-file-securely is a better name than file-rename, and similarly for other functions). It's basically the same situation as with, say, strtok vs strtok_r, to take just one similar example. Whether people want "M-x foo bar" produce bar/foo or just bar, is open to argument. My impression is that they want the former, because it is what "mv foo bar" does by default when bar is a directory. Note that mv doesn't require a trailing slash in this case, and it gives the user an explicit opt-in switch to change the behavior to the one you proposed. (We could provide such an optional argument as well, as an alternative to introducing new functions.)