From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: master 739593d 3/5: Make gnus-copy-file act like copy-file etc. Date: Wed, 13 Sep 2017 13:41:25 -0700 Organization: UCLA Computer Science Department Message-ID: <122fe4a2-2e96-9167-c815-42aa962c3da0@cs.ucla.edu> References: <20170911053128.28763.28434@vcs0.savannah.gnu.org> <20170911053130.C5F002068F@vcs0.savannah.gnu.org> <87o9qecs1t.fsf@mouse.gnus.org> <87a81ycqau.fsf@mouse.gnus.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1505335299 5026 195.159.176.226 (13 Sep 2017 20:41:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 13 Sep 2017 20:41:39 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 Cc: Katsumi Yamaoka , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 13 22:41:34 2017 Return-path: Envelope-to: ged-emacs-devel@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 1dsETU-0001As-An for ged-emacs-devel@m.gmane.org; Wed, 13 Sep 2017 22:41:32 +0200 Original-Received: from localhost ([::1]:44604 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dsETb-0006BC-KO for ged-emacs-devel@m.gmane.org; Wed, 13 Sep 2017 16:41:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dsETU-0006B0-Vb for emacs-devel@gnu.org; Wed, 13 Sep 2017 16:41:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dsETR-0005YQ-23 for emacs-devel@gnu.org; Wed, 13 Sep 2017 16:41:33 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45896) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dsETQ-0005Xb-Re for emacs-devel@gnu.org; Wed, 13 Sep 2017 16:41:28 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 64AF1160D01; Wed, 13 Sep 2017 13:41:26 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id aZRAXWkWUwI8; Wed, 13 Sep 2017 13:41:25 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 96A0F160D05; Wed, 13 Sep 2017 13:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kSPNzmk-nOBL; Wed, 13 Sep 2017 13:41:25 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7BFE516096F; Wed, 13 Sep 2017 13:41:25 -0700 (PDT) In-Reply-To: <87a81ycqau.fsf@mouse.gnus.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:218220 Archived-At: On 09/13/2017 01:11 PM, Lars Ingebrigtsen wrote: > What are the security implications of writing the file to the directory > if the user (interactively) types in that directory name? If the attacker knows what the user is up to (and this can be guessed often enough by looking at what Emacs has done to the file system recently), the attacker can hijack the rename. For example, if you type 'M-x rename-file RET abc RET /tmp/def RET', the attacker can create a symlink /tmp/def to a victim directory D so that the file abc is moved to D/abc rather than to its intended location /tmp/def. This attack can happen only when the destination's parent directory (/tmp in the above example) is writable to the attacker. So we could bring back support for interactive renames to destination directories whose parents are writable only by self or root. (Most likely the actual rule will be more complicated than this, but the basic idea will work.) This would lessen the scope of the change, albeit at the cost of complication of the documentation and implementation. > The user can type anything, like "/home/larsi" and "/var/tmp" and the > behaviour should be the same across directories. /home/larsi and /var/tmp should both be safe destinations in the above sense, as their parents aren't writable to others. So they would both work without the trailing slash, under the above proposal. I'd rather leave it alone as it's simpler and easier to describe the way it is, and I type the same keystrokes as before since I normally use tab completion which adds a trailing / which gives me visual feedback that it's a move into a directory which is a win. But I can be talked into something like the above if it'd be valuable for others' interactive use. (Do you type "/ h o m e / l a r s i" by hand a lot? :-)