From unknown Mon Jun 23 02:21:16 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#27986 <27986@debbugs.gnu.org> To: bug#27986 <27986@debbugs.gnu.org> Subject: Status: 26.0.50; `rename-file' can rename files without confirmation Reply-To: bug#27986 <27986@debbugs.gnu.org> Date: Mon, 23 Jun 2025 09:21:16 +0000 retitle 27986 26.0.50; `rename-file' can rename files without confirmation reassign 27986 emacs submitter 27986 Philipp severity 27986 important tag 27986 security thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 06 11:40:40 2017 Received: (at submit) by debbugs.gnu.org; 6 Aug 2017 15:40:40 +0000 Received: from localhost ([127.0.0.1]:44878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deNfU-0000w4-6q for submit@debbugs.gnu.org; Sun, 06 Aug 2017 11:40:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deNfS-0000vp-CT for submit@debbugs.gnu.org; Sun, 06 Aug 2017 11:40:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1deNfL-0001Qg-RR for submit@debbugs.gnu.org; Sun, 06 Aug 2017 11:40:33 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_50, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:50342) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1deNfL-0001Qa-Ob for submit@debbugs.gnu.org; Sun, 06 Aug 2017 11:40:31 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43530) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deNfK-0005l7-6W for bug-gnu-emacs@gnu.org; Sun, 06 Aug 2017 11:40:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1deNfE-0001OD-Em for bug-gnu-emacs@gnu.org; Sun, 06 Aug 2017 11:40:30 -0400 Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:37712) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1deNfE-0001NY-7b for bug-gnu-emacs@gnu.org; Sun, 06 Aug 2017 11:40:24 -0400 Received: by mail-wm0-x230.google.com with SMTP id t201so51779918wmt.0 for ; Sun, 06 Aug 2017 08:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=w8pnJj3ZpX3M0bRLtKxGtrdBMCtb60cYNn5fTLJgGRU=; b=qa+EK7c6COtR+zAUMM0ilTuiRqWfDyPwvuZkCK+ADruJWKHxg/unQXajEDof7I9YK8 DzcbZSLNu7lhBqYuV423PYQ9zGqU8n6XoLEW9ffrOIc1pxE+DGaUNUj7TovqyIRkY2Cq EmlALtAVrGxtbA0MLq340waC8hPPuJ25ueTC98aQELwBVQi4wcyYrzmaMqpn+APi/21/ zHB2bTGXnp0ijHg2YQW5RoRRzAiIgo8ihV28Wk72w6nrFnPfVHK0S/J6Q7rqvvjAoKh/ i1MlxMdyExq0lWXIAWJHnV4SrwPVfrdfhvzMfmm8hI36300K1MAELUc3dRFe0BgV9Usk EZaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=w8pnJj3ZpX3M0bRLtKxGtrdBMCtb60cYNn5fTLJgGRU=; b=X8MB0b8APhDZdgIn1wL6fFlk88A/WiAN7YBKxUFgGQr58PN/jjmWQiHLeiqkEE1XoF hhJP6KjmZMsD/M+FV8ZgBYoXsJOtyOPnXE8JNX94paiaMT0GgQToN8bi08KlGEgC7KXE FnOSFDixjqts4vQWGpmQ1qBPNayZ0IF57dKQ2TbYi+1UVcHXRfpiiU54b0HmoKkF0EZC K/AcuywF9UCkeDkuI+ibCnzeizHl8AfIDVUuO2ILQFF/HzmMZoKItXRsTGMLB8+LfIFl FhdzBGP4sg/02dnWMQXaUfKM3DoZKAO38TujfCRGb1qNXMwS0Cb56rWZev4IQflxZyJL Fq6Q== X-Gm-Message-State: AHYfb5jLiFAC5iAg4QFdXIdwkVEQiw8iYwXPtOl7K5UW/LJjxQcwiuX5 7UH8W1bJ+tTZbOW7x5E= X-Received: by 10.28.230.18 with SMTP id d18mr1636252wmh.56.1502034021209; Sun, 06 Aug 2017 08:40:21 -0700 (PDT) Received: from p ([2001:4c50:256:ae00:21eb:966:f36b:fdde]) by smtp.gmail.com with ESMTPSA id d20sm7500967wrc.96.2017.08.06.08.40.20 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 06 Aug 2017 08:40:20 -0700 (PDT) From: Philipp To: bug-gnu-emacs@gnu.org Subject: 26.0.50; `rename-file' can rename files without confirmation Date: Sun, 06 Aug 2017 17:40:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) Run the following in *scratch*: (make-directory "/tmp/emacs") nil (write-region "" nil "/tmp/emacs/=C3=9F") nil (write-region "" nil "/tmp/emacs/=E1=BA=9E") nil (directory-files "/tmp/emacs") ("." ".." "=C3=9F" "=E1=BA=9E") (rename-file "/tmp/emacs/=E1=BA=9E" "/tmp/emacs/=C3=9F") nil Note how `rename-file' has silently overwritten `=C3=9F'. This is because = on macOS, `=C3=9F' and `=E1=BA=9E' are different file names, but Emacs treats = them as equal. Probably the test for case-insensitive file names should be removed altogether (it can't work correctly and introduces a filesystem race), and `rename-file' should use link(2) + unlink(2) if renameat2 isn't available. In GNU Emacs 26.0.50 (build 77, x86_64-apple-darwin16.7.0, NS appkit-1504.8= 3 Version 10.12.6 (Build 16G29)) of 2017-08-06 built on p Repository revision: b1b99edd3ee587a5154106d4d16547eac4916c55 Windowing system distributor 'Apple', version 10.3.1504 Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --with-modules --without-xml2 --without-pop --with-mailutils --enable-gcc-warnings=3Dyes MAKEINFO=3D/usr/local/opt/texinfo/bin/makeinfo 'CFLAGS=3D-O3 -g0' LDFLAGS=3D-O3' Configured features: DBUS NOTIFY ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS NS MODULES Important settings: value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind kqueue cocoa ns multi-tty make-network-process emacs) Memory information: ((conses 16 204143 9065) (symbols 48 20146 1) (miscs 40 43 181) (strings 32 29176 1731) (string-bytes 1 784929) (vectors 16 35010) (vector-slots 8 710995 9656) (floats 8 48 68) (intervals 56 205 0) (buffers 992 11)) From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 06 13:05:25 2017 Received: (at 27986) by debbugs.gnu.org; 6 Aug 2017 17:05:26 +0000 Received: from localhost ([127.0.0.1]:44931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deOzV-00032R-MT for submit@debbugs.gnu.org; Sun, 06 Aug 2017 13:05:25 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deOzU-00032F-5z for 27986@debbugs.gnu.org; Sun, 06 Aug 2017 13:05:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1deOzL-0002l5-Jx for 27986@debbugs.gnu.org; Sun, 06 Aug 2017 13:05:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deOzL-0002kv-GS; Sun, 06 Aug 2017 13:05:15 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3255 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1deOzK-0001QX-Ul; Sun, 06 Aug 2017 13:05:15 -0400 Date: Sun, 06 Aug 2017 20:05:09 +0300 Message-Id: <83poc8tynu.fsf@gnu.org> From: Eli Zaretskii To: Philipp In-reply-to: (message from Philipp on Sun, 06 Aug 2017 17:40:18 +0200) Subject: Re: bug#27986: 26.0.50; `rename-file' can rename files without confirmation References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Philipp > Date: Sun, 06 Aug 2017 17:40:18 +0200 > > (rename-file "/tmp/emacs/ẞ" "/tmp/emacs/ß") > nil > > Note how `rename-file' has silently overwritten `ß'. This is because on > macOS, `ß' and `ẞ' are different file names, but Emacs treats them as > equal. Probably the test for case-insensitive file names should be > removed altogether Which one? there are two of them. > (it can't work correctly and introduces a filesystem race) It cannot work correctly _because_ of a possible race or because of some other reasons? If the latter, please elaborate. If the former, then at least on MS-Windows we have a race anyway, because the underlying system APIs are not atomic. So at least on MS-Windows the feature should stay, as it introduces no new issues and supports a valid and quite important use case (the Windows shell supports it as well, so we really cannot do less). > and `rename-file' should use link(2) + unlink(2) if renameat2 > isn't available. 'link' and 'unlink' accept strings as arguments, not integer numbers such as 2. More to the point, how can this strategy work on a case-insensitive filesystem? What am I missing? From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 11 04:15:28 2017 Received: (at 27986) by debbugs.gnu.org; 11 Aug 2017 08:15:28 +0000 Received: from localhost ([127.0.0.1]:55109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dg56M-0006Hp-45 for submit@debbugs.gnu.org; Fri, 11 Aug 2017 04:15:26 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dg56I-00067n-Dy for 27986@debbugs.gnu.org; Fri, 11 Aug 2017 04:15:23 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DBF1C16081F; Fri, 11 Aug 2017 01:15:15 -0700 (PDT) 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 uDgM-yBAxd5U; Fri, 11 Aug 2017 01:15:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4E1CA160821; Fri, 11 Aug 2017 01:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 wRXKSB58gkA8; Fri, 11 Aug 2017 01:15:14 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 232BF16081F; Fri, 11 Aug 2017 01:15:14 -0700 (PDT) To: Eli Zaretskii From: Paul Eggert Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation Organization: UCLA Computer Science Department Message-ID: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> Date: Fri, 11 Aug 2017 01:15:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010434A5D07DB431825F2CDF" Content-Language: en-US X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: Philipp , 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) This is a multi-part message in MIME format. --------------010434A5D07DB431825F2CDF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >> Probably the test for case-insensitive file names should be >> removed altogether >=20 > Which one? there are two of them. There should be just one such test, since it's testing the same thing and= =20 there's no point to doing the same test twice. And I notice the code has = some=20 other duplicate system calls. I installed the attached patch, which prune= s away=20 some of these duplicates. With this patch, (rename-file "a" "b/") now tak= es just=20 one system call on recent GNU/Linux, whereas it used to take four (and wa= s not=20 atomic). However, even with this patch there are races on GNU/Linux which can lead= to=20 potential security problems. Perhaps we can't fix these races on MS-Windo= ws but=20 we should be able to fix them on a GNUish host. However, we will need to = change=20 the semantics of rename-file etc. slightly, since no single system call s= upports=20 the cp-like target rewriting of these functions. I have a fix in mind to = do that=20 in a hopefully compatible-enough way, which I'll try to propose soon. I'l= l keep=20 case-insensitive file systems in mind when I do that. This reminds me of a similar problem in GNU coreutils which I fixed a doz= en=20 years ago by adding the -T option to mv, ln, etc. --------------010434A5D07DB431825F2CDF Content-Type: text/x-patch; name="0001-Improve-performance-for-rename-file-etc.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Improve-performance-for-rename-file-etc.patch" =46rom a56e6e79613779895975b1762c311bf8fe46f551 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 11 Aug 2017 01:04:30 -0700 Subject: [PATCH] Improve performance for rename-file etc. Although this does not fix Bug#27986, it is a step forward. I plan to propose a more-significant patch later. * lisp/files.el (directory-name-p): Move from here ... * src/fileio.c (Fdirectory_name_p): ... to here. (directory_like, cp_like_target): New static functions. (Fcopy_file, Frename_file, Fadd_name_to_file) (Fmake_symbolic_link): Use them, to avoid directory-testing syscalls on file names that must be directories if they exist. Omit unnecessary initializations and CHECK_STRING calls. (Frename_file): Don't call file_name_case_insensitive_p twice on the same file. Compare both file names expanded, instead of the old name expanded and the new one unexpanded. --- lisp/files.el | 10 ----- src/fileio.c | 127 ++++++++++++++++++++++++++++++----------------------= ------ 2 files changed, 66 insertions(+), 71 deletions(-) diff --git a/lisp/files.el b/lisp/files.el index f2758ab..0fe7f9c 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -792,16 +792,6 @@ cd (lambda (f) (and (file-directory-p f) 'dir-ok))) (error "No such directory found via CDPATH environment variable")= ))) =20 -(defsubst directory-name-p (name) - "Return non-nil if NAME ends with a directory separator character." - (let ((len (length name)) - (lastc ?.)) - (if (> len 0) - (setq lastc (aref name (1- len)))) - (or (=3D lastc ?/) - (and (memq system-type '(windows-nt ms-dos)) - (=3D lastc ?\\))))) - (defun directory-files-recursively (dir regexp &optional include-directo= ries) "Return list of all files under DIR that have file names matching REGE= XP. This function works recursively. Files are returned in \"depth first\" diff --git a/src/fileio.c b/src/fileio.c index 15845e3..9aae7d9 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -267,9 +267,9 @@ Otherwise, return nil. A file name is handled if one of the regular expressions in `file-name-handler-alist' matches it. =20 -If OPERATION equals `inhibit-file-name-operation', then we ignore +If OPERATION equals `inhibit-file-name-operation', then ignore any handlers that are members of `inhibit-file-name-handlers', -but we still do run any other handlers. This lets handlers +but still do run any other handlers. This lets handlers use the standard functions without calling themselves recursively. */) (Lisp_Object filename, Lisp_Object operation) { @@ -583,6 +583,38 @@ directory_file_name (char *dst, char *src, ptrdiff_t= srclen, bool multibyte) return srclen; } =20 +DEFUN ("directory-name-p", Fdirectory_name_p, Sdirectory_name_p, 1, 1, 0= , + doc: /* Return non-nil if NAME ends with a directory separator ch= aracter. */) + (Lisp_Object name) +{ + CHECK_STRING (name); + ptrdiff_t namelen =3D SBYTES (name); + unsigned char c =3D namelen ? SREF (name, namelen - 1) : 0; + return IS_DIRECTORY_SEP (c) ? Qt : Qnil; +} + +/* Return true if NAME must be that of a directory if it exists. + When NAME is a directory name, this avoids system calls compared to + just calling Ffile_directory_p. */ + +static bool +directory_like (Lisp_Object name) +{ + return !NILP (Fdirectory_name_p (name)) || !NILP (Ffile_directory_p (n= ame)); +} + +/* Return the expansion of NEWNAME, except that if NEWNAME is like a + directory then return the expansion of FILE's basename under + NEWNAME. This is like how 'cp FILE NEWNAME' works. */ + +static Lisp_Object +expand_cp_target (Lisp_Object file, Lisp_Object newname) +{ + return (directory_like (newname) + ? Fexpand_file_name (Ffile_name_nondirectory (file), newname) + : Fexpand_file_name (newname, Qnil)); +} + DEFUN ("directory-file-name", Fdirectory_file_name, Sdirectory_file_name= , 1, 1, 0, doc: /* Returns the file name of the directory named DIRECTORY. @@ -1874,9 +1906,9 @@ This function always sets the file modes of the out= put file to match the input file. =20 The optional third argument OK-IF-ALREADY-EXISTS specifies what to do -if file NEWNAME already exists. If OK-IF-ALREADY-EXISTS is nil, we +if file NEWNAME already exists. If OK-IF-ALREADY-EXISTS is nil, signal a `file-already-exists' error without overwriting. If -OK-IF-ALREADY-EXISTS is a number, we request confirmation from the user +OK-IF-ALREADY-EXISTS is an integer, request confirmation from the user about overwriting; this is what happens in interactive use with M-x. Any other value for OK-IF-ALREADY-EXISTS means to overwrite the existing file. @@ -1886,8 +1918,8 @@ last-modified time as the old one. (This works on = only some systems.) =20 A prefix arg makes KEEP-TIME non-nil. =20 -If PRESERVE-UID-GID is non-nil, we try to transfer the -uid and gid of FILE to NEWNAME. +If PRESERVE-UID-GID is non-nil, try to transfer the uid and gid of +FILE to NEWNAME. =20 If PRESERVE-PERMISSIONS is non-nil, copy permissions of FILE to NEWNAME;= this includes the file modes, along with ACL entries and SELinux @@ -1914,16 +1946,8 @@ permissions. */) struct stat st; #endif =20 - encoded_file =3D encoded_newname =3D Qnil; - CHECK_STRING (file); - CHECK_STRING (newname); - - if (!NILP (Ffile_directory_p (newname))) - newname =3D Fexpand_file_name (Ffile_name_nondirectory (file), newna= me); - else - newname =3D Fexpand_file_name (newname, Qnil); - file =3D Fexpand_file_name (file, Qnil); + newname =3D expand_cp_target (file, newname); =20 /* If the input file name has special constructs in it, call the corresponding file handler. */ @@ -2304,9 +2328,9 @@ DEFUN ("rename-file", Frename_file, Srename_file, 2= , 3, "fRename file: \nGRename %s to file: \np", doc: /* Rename FILE as NEWNAME. Both args must be strings. If file has names other than FILE, it continues to have those names. -Signals a `file-already-exists' error if a file NEWNAME already exists +Signal a `file-already-exists' error if a file NEWNAME already exists unless optional third argument OK-IF-ALREADY-EXISTS is non-nil. -A number as third arg means request confirmation if NEWNAME already exis= ts. +An integer third arg means request confirmation if NEWNAME already exist= s. This is what happens in interactive use with M-x. */) (Lisp_Object file, Lisp_Object newname, Lisp_Object ok_if_already_exis= ts) { @@ -2314,24 +2338,22 @@ This is what happens in interactive use with M-x.= */) Lisp_Object encoded_file, encoded_newname, symlink_target; int dirp =3D -1; =20 - symlink_target =3D encoded_file =3D encoded_newname =3D Qnil; - CHECK_STRING (file); - CHECK_STRING (newname); file =3D Fexpand_file_name (file, Qnil); =20 - if ((!NILP (Ffile_directory_p (newname))) - /* If the filesystem is case-insensitive and the file names are - identical but for the case, don't attempt to move directory - to itself. */ - && (NILP (Ffile_name_case_insensitive_p (file)) - || NILP (Fstring_equal (Fdowncase (file), Fdowncase (newname))))) + /* If the filesystem is case-insensitive and the file names are + identical but for case, treat it as a change-case request, and do + not worry whether NEWNAME exists or whether it is a directory, as + it is already another name for FILE. */ + bool case_only_rename =3D false; + if (!NILP (Ffile_name_case_insensitive_p (file))) { - dirp =3D !NILP (Ffile_directory_p (file)); - Lisp_Object fname =3D dirp ? Fdirectory_file_name (file) : file; - newname =3D Fexpand_file_name (Ffile_name_nondirectory (fname), ne= wname); + newname =3D Fexpand_file_name (newname, Qnil); + case_only_rename =3D !NILP (Fstring_equal (Fdowncase (file), + Fdowncase (newname))); } - else - newname =3D Fexpand_file_name (newname, Qnil); + + if (!case_only_rename) + newname =3D expand_cp_target (Fdirectory_file_name (file), newname);= =20 /* If the file name has special constructs in it, call the corresponding file handler. */ @@ -2345,15 +2367,9 @@ This is what happens in interactive use with M-x. = */) encoded_file =3D ENCODE_FILE (file); encoded_newname =3D ENCODE_FILE (newname); =20 - /* If the filesystem is case-insensitive and the file names are - identical but for the case, don't worry whether the destination - already exists: the caller simply wants to change the letter-case - of the file name. */ - bool plain_rename - =3D ((!NILP (ok_if_already_exists) && !INTEGERP (ok_if_already_exist= s)) - || (file_name_case_insensitive_p (SSDATA (encoded_file)) - && ! NILP (Fstring_equal (Fdowncase (file), Fdowncase (newname)))));= - + bool plain_rename =3D (case_only_rename + || (!NILP (ok_if_already_exists) + && !INTEGERP (ok_if_already_exists))); int rename_errno; if (!plain_rename) { @@ -2395,7 +2411,7 @@ This is what happens in interactive use with M-x. = */) else { if (dirp < 0) - dirp =3D !NILP (Ffile_directory_p (file)); + dirp =3D directory_like (file); if (dirp) call4 (Qcopy_directory, file, newname, Qt, Qnil); else @@ -2414,24 +2430,17 @@ This is what happens in interactive use with M-x.= */) DEFUN ("add-name-to-file", Fadd_name_to_file, Sadd_name_to_file, 2, 3, "fAdd name to file: \nGName to add to %s: \np", doc: /* Give FILE additional name NEWNAME. Both args must be str= ings. -Signals a `file-already-exists' error if a file NEWNAME already exists +Signal a `file-already-exists' error if a file NEWNAME already exists unless optional third argument OK-IF-ALREADY-EXISTS is non-nil. -A number as third arg means request confirmation if NEWNAME already exis= ts. +An integer third arg means request confirmation if NEWNAME already exist= s. This is what happens in interactive use with M-x. */) (Lisp_Object file, Lisp_Object newname, Lisp_Object ok_if_already_exis= ts) { Lisp_Object handler; Lisp_Object encoded_file, encoded_newname; =20 - encoded_file =3D encoded_newname =3D Qnil; - CHECK_STRING (file); - CHECK_STRING (newname); file =3D Fexpand_file_name (file, Qnil); - - if (!NILP (Ffile_directory_p (newname))) - newname =3D Fexpand_file_name (Ffile_name_nondirectory (file), newna= me); - else - newname =3D Fexpand_file_name (newname, Qnil); + newname =3D expand_cp_target (file, newname); =20 /* If the file name has special constructs in it, call the corresponding file handler. */ @@ -2471,28 +2480,23 @@ DEFUN ("make-symbolic-link", Fmake_symbolic_link,= Smake_symbolic_link, 2, 3, "FMake symbolic link to file: \nGMake symbolic link to file %s: \= np", doc: /* Make a symbolic link to TARGET, named LINKNAME. Both args must be strings. -Signals a `file-already-exists' error if a file LINKNAME already exists +Signal a `file-already-exists' error if a file LINKNAME already exists unless optional third argument OK-IF-ALREADY-EXISTS is non-nil. -A number as third arg means request confirmation if LINKNAME already exi= sts. +An integer third arg means request confirmation if LINKNAME already exis= ts. This happens for interactive use with M-x. */) (Lisp_Object target, Lisp_Object linkname, Lisp_Object ok_if_already_e= xists) { Lisp_Object handler; Lisp_Object encoded_target, encoded_linkname; =20 - encoded_target =3D encoded_linkname =3D Qnil; CHECK_STRING (target); - CHECK_STRING (linkname); /* If the link target has a ~, we must expand it to get a truly valid file name. Otherwise, do not expand; we want to permit links to relative file names. */ if (SREF (target, 0) =3D=3D '~') target =3D Fexpand_file_name (target, Qnil); =20 - if (!NILP (Ffile_directory_p (linkname))) - linkname =3D Fexpand_file_name (Ffile_name_nondirectory (target), li= nkname); - else - linkname =3D Fexpand_file_name (linkname, Qnil); + linkname =3D expand_cp_target (target, linkname); =20 /* If the file name has special constructs in it, call the corresponding file handler. */ @@ -5577,7 +5581,7 @@ and are changed since last auto-saved. Auto-saving writes the buffer into a file so that your editing is not lost if the system crashes. This file is not the file you visited; that changes only when you save. -Normally we run the normal hook `auto-save-hook' before saving. +Normally, run the normal hook `auto-save-hook' before saving. =20 A non-nil NO-MESSAGE argument means do not print any message if successf= ul. A non-nil CURRENT-ONLY argument means save only current buffer. */) @@ -6111,7 +6115,7 @@ This applies only to the operation `inhibit-file-na= me-operation'. */); Vinhibit_file_name_operation =3D Qnil; =20 DEFVAR_LISP ("auto-save-list-file-name", Vauto_save_list_file_name, - doc: /* File name in which we write a list of all auto save file= names. + doc: /* File name in which to write a list of all auto save file= names. This variable is initialized automatically from `auto-save-list-file-pre= fix' shortly after Emacs reads your init file, if you have not yet given it a non-nil value. */); @@ -6166,6 +6170,7 @@ This includes interactive calls to `delete-file' an= d defsubr (&Sfile_name_nondirectory); defsubr (&Sunhandled_file_name_directory); defsubr (&Sfile_name_as_directory); + defsubr (&Sdirectory_name_p); defsubr (&Sdirectory_file_name); defsubr (&Smake_temp_name); defsubr (&Sexpand_file_name); --=20 2.7.4 --------------010434A5D07DB431825F2CDF-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 13 18:42:16 2017 Received: (at 27986) by debbugs.gnu.org; 13 Aug 2017 22:42:16 +0000 Received: from localhost ([127.0.0.1]:33201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dh1aJ-0001MS-Gw for submit@debbugs.gnu.org; Sun, 13 Aug 2017 18:42:16 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37198) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dh1aH-0001MM-45 for 27986@debbugs.gnu.org; Sun, 13 Aug 2017 18:42:13 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8769C16084B; Sun, 13 Aug 2017 15:42:07 -0700 (PDT) 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 Xz3DGkAfC-HO; Sun, 13 Aug 2017 15:42:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 14D2C160759; Sun, 13 Aug 2017 15:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 mTcamVdTsvuH; Sun, 13 Aug 2017 15:42:05 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id DA72F160734; Sun, 13 Aug 2017 15:42:05 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation From: Paul Eggert To: Eli Zaretskii References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> Organization: UCLA Computer Science Department Message-ID: <1002ee73-0ab5-409b-831f-0c283c322264@cs.ucla.edu> Date: Sun, 13 Aug 2017 15:42:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> Content-Type: multipart/mixed; boundary="------------004A3577E8D9E540D7659E5C" Content-Language: en-US X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: Philipp , 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) This is a multi-part message in MIME format. --------------004A3577E8D9E540D7659E5C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Paul Eggert wrote: > there are races on GNU/Linux which can lead to potential security probl= ems.=20 > Perhaps we can't fix these races on MS-Windows but we should be able to= fix them=20 > on a GNUish host. However, we will need to change the semantics of rena= me-file=20 > etc. slightly, since no single system call supports the cp-like target = rewriting=20 > of these functions. I have a fix in mind to do that in a hopefully=20 > compatible-enough way, which I'll try to propose soon. I'll keep=20 > case-insensitive file systems in mind when I do that. Attached is a proposed patch to fix this security problem. If I understan= d=20 things correctly, the fix should work on MS-Windows and on case-insensiti= ve file=20 systems. Since this patch entails an incompatible change to the (undocume= nted)=20 behavior of (rename-file A B) when B is a directory but is not a director= y name,=20 I'll mention the proposed change on emacs-devel. --------------004A3577E8D9E540D7659E5C Content-Type: text/x-patch; name="0001-Fix-race-with-rename-file-etc.-with-dir-NEWNAME.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="0001-Fix-race-with-rename-file-etc.-with-dir-NEWNAME.patch" =46rom 967d1c009f6743aa75e6829129ea9445ebc06f30 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 13 Aug 2017 15:20:56 -0700 Subject: [PROPOSED] Fix race with rename-file etc. with dir NEWNAME This changes the behavior of rename-file etc. slightly. The old behavior mostly disagreed with the documentation, and had a race condition bug that could allow attackers to modify victims' write-protected directories. * doc/lispref/files.texi (Changing Files): Document that in rename-file etc., NEWFILE is special if it is a directory name. * etc/NEWS: Document the change in behavior. * src/fileio.c (directory_like): Remove. All uses removed. (expand_cp_target): Test only whether NEWNAME is a directory name, not whether it is currently a directory. This avoids a race. (Fcopy_file, Frename_file, Fadd_name_to_file, Fmake_symbolic_link): Document behavior if NEWNAME is a directory name. (Frename_file): Simplify now that the destdir behavior occurs only when NEWNAME is a directory name. * test/lisp/net/tramp-tests.el (tramp-test11-copy-file) (tramp-test12-rename-file, tramp--test-check-files): Adjust tests to match new behavior. --- doc/lispref/files.texi | 10 +++++--- etc/NEWS | 13 +++++++++++ src/fileio.c | 55 ++++++++++++++++++++++----------------= ------ test/lisp/net/tramp-tests.el | 16 ++++++------- 4 files changed, 55 insertions(+), 39 deletions(-) diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi index 25f32c231c..8956c4f1b7 100644 --- a/doc/lispref/files.texi +++ b/doc/lispref/files.texi @@ -1553,9 +1553,13 @@ Changing Files made by these functions instead of writing them immediately to secondary storage. @xref{Files and Storage}. =20 - In the functions that have an argument @var{newname}, if a file by the= -name of @var{newname} already exists, the actions taken depend on the -value of the argument @var{ok-if-already-exists}: + In the functions that have an argument @var{newname}, if +this argument is a directory name it is treated as if the nondirectory +part of the source name were appended. For example, if the old name is +@code{"a/b/c"}, the @var{newname} @code{"d/e/f/"} is treated as if it +were @code{"d/e/f/c"}. Furthermore, if a file already exists with the +new name, the actions taken depend on the value of the argument +@var{ok-if-already-exists}: =20 @itemize @bullet @item diff --git a/etc/NEWS b/etc/NEWS index 3f38153048..947114148b 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1204,6 +1204,19 @@ break. ** The arguments LOCKNAME and MUSTBENEW of 'write-region' are propagated to file name handlers now. =20 ++++ +** When the NEWNAME argument of 'copy-file', 'rename-file', +'add-name-to-file', or 'make-symbolic-link' is an existing directory +and the intent is to act on an entry in that directory, NEWNAME should +now be a directory name, e.g., (rename-file "e" "f/") renames to 'f/e'. +Although this formerly happened sometimes even when NEWNAME was not a +directory name, as in (rename-file "e" "f") where 'f' happened to be a +directory, the old behavior had inherent races that led to security +holes, and disagreed with longstanding documentation. A call like +(rename-file A B) that used the old, undocumented behavior can be +written as (rename-file A (file-name-as-directory B)), a formulation +portable to both older and newer versions of Emacs. + =0C * Lisp Changes in Emacs 26.1 =20 diff --git a/src/fileio.c b/src/fileio.c index 69079c6ae4..4bfa915951 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -594,24 +594,16 @@ DEFUN ("directory-name-p", Fdirectory_name_p, Sdire= ctory_name_p, 1, 1, 0, return IS_DIRECTORY_SEP (c) ? Qt : Qnil; } =20 -/* Return true if NAME must be that of a directory if it exists. - When NAME is a directory name, this avoids system calls compared to - just calling Ffile_directory_p. */ - -static bool -directory_like (Lisp_Object name) -{ - return !NILP (Fdirectory_name_p (name)) || !NILP (Ffile_directory_p (n= ame)); -} - -/* Return the expansion of NEWNAME, except that if NEWNAME is like a - directory then return the expansion of FILE's basename under - NEWNAME. This is like how 'cp FILE NEWNAME' works. */ +/* Return the expansion of NEWNAME, except that if NEWNAME is a + directory name then return the expansion of FILE's basename under + NEWNAME. This resembles how 'cp FILE NEWNAME' works, except that + it requires NEWNAME to be a directory name (typically, by ending in + "/"). */ =20 static Lisp_Object expand_cp_target (Lisp_Object file, Lisp_Object newname) { - return (directory_like (newname) + return (!NILP (Fdirectory_name_p (newname)) ? Fexpand_file_name (Ffile_name_nondirectory (file), newname) : Fexpand_file_name (newname, Qnil)); } @@ -1818,7 +1810,8 @@ clone_file (int dest, int source) DEFUN ("copy-file", Fcopy_file, Scopy_file, 2, 6, "fCopy file: \nGCopy %s to file: \np\nP", doc: /* Copy FILE to NEWNAME. Both args must be strings. -If NEWNAME names a directory, copy FILE there. +If NEWNAME is a directory name, copy FILE to a like-named file under +NEWNAME. =20 This function always sets the file modes of the output file to match the input file. @@ -2242,6 +2235,9 @@ DEFUN ("rename-file", Frename_file, Srename_file, 2= , 3, "fRename file: \nGRename %s to file: \np", doc: /* Rename FILE as NEWNAME. Both args must be strings. If file has names other than FILE, it continues to have those names. +If NEWNAME is a directory name, rename FILE to a like-named file under +NEWNAME. + Signal a `file-already-exists' error if a file NEWNAME already exists unless optional third argument OK-IF-ALREADY-EXISTS is non-nil. An integer third arg means request confirmation if NEWNAME already exist= s. @@ -2250,7 +2246,6 @@ This is what happens in interactive use with M-x. = */) { Lisp_Object handler; Lisp_Object encoded_file, encoded_newname, symlink_target; - int dirp =3D -1; =20 file =3D Fexpand_file_name (file, Qnil); =20 @@ -2319,22 +2314,21 @@ This is what happens in interactive use with M-x.= */) if (rename_errno !=3D EXDEV) report_file_errno ("Renaming", list2 (file, newname), rename_errno);= =20 - symlink_target =3D Ffile_symlink_p (file); - if (!NILP (symlink_target)) - Fmake_symbolic_link (symlink_target, newname, ok_if_already_exists);= + bool dirp =3D !NILP (Fdirectory_name_p (file)); + if (dirp) + call4 (Qcopy_directory, file, newname, Qt, Qnil); else { - if (dirp < 0) - dirp =3D directory_like (file); - if (dirp) - call4 (Qcopy_directory, file, newname, Qt, Qnil); + symlink_target =3D Ffile_symlink_p (file); + if (!NILP (symlink_target)) + Fmake_symbolic_link (symlink_target, newname, ok_if_already_exists); else Fcopy_file (file, newname, ok_if_already_exists, Qt, Qt, Qt); } =20 ptrdiff_t count =3D SPECPDL_INDEX (); specbind (Qdelete_by_moving_to_trash, Qnil); - if (dirp && NILP (symlink_target)) + if (dirp) call2 (Qdelete_directory, file, Qt); else Fdelete_file (file, Qnil); @@ -2344,6 +2338,9 @@ This is what happens in interactive use with M-x. = */) DEFUN ("add-name-to-file", Fadd_name_to_file, Sadd_name_to_file, 2, 3, "fAdd name to file: \nGName to add to %s: \np", doc: /* Give FILE additional name NEWNAME. Both args must be str= ings. +If NEWNAME is a directory name, give FILE a like-named new name under +NEWNAME. + Signal a `file-already-exists' error if a file NEWNAME already exists unless optional third argument OK-IF-ALREADY-EXISTS is non-nil. An integer third arg means request confirmation if NEWNAME already exist= s. @@ -2392,11 +2389,13 @@ This is what happens in interactive use with M-x.= */) =20 DEFUN ("make-symbolic-link", Fmake_symbolic_link, Smake_symbolic_link, 2= , 3, "FMake symbolic link to file: \nGMake symbolic link to file %s: \= np", - doc: /* Make a symbolic link to TARGET, named LINKNAME. -Both args must be strings. -Signal a `file-already-exists' error if a file LINKNAME already exists + doc: /* Make a symbolic link to TARGET, named NEWNAME. +If NEWNAME is a directory name, make a like-named symbolic link under +NEWNAME. + +Signal a `file-already-exists' error if a file NEWNAME already exists unless optional third argument OK-IF-ALREADY-EXISTS is non-nil. -An integer third arg means request confirmation if LINKNAME already exis= ts. +An integer third arg means request confirmation if NEWNAME already exist= s. This happens for interactive use with M-x. */) (Lisp_Object target, Lisp_Object linkname, Lisp_Object ok_if_already_e= xists) { diff --git a/test/lisp/net/tramp-tests.el b/test/lisp/net/tramp-tests.el index 45cf95fcfe..6aca0a278e 100644 --- a/test/lisp/net/tramp-tests.el +++ b/test/lisp/net/tramp-tests.el @@ -1892,7 +1892,7 @@ tramp--test-backtrace (should-error (copy-file tmp-name1 tmp-name2)) (copy-file tmp-name1 tmp-name2 'ok) (make-directory tmp-name3) - (copy-file tmp-name1 tmp-name3) + (copy-file tmp-name1 (file-name-as-directory tmp-name3)) (should (file-exists-p (expand-file-name (file-name-nondirectory tmp-name1) tmp-name3)))= ) @@ -1914,7 +1914,7 @@ tramp--test-backtrace (should-error (copy-file tmp-name1 tmp-name4)) (copy-file tmp-name1 tmp-name4 'ok) (make-directory tmp-name5) - (copy-file tmp-name1 tmp-name5) + (copy-file tmp-name1 (file-name-as-directory tmp-name5)) (should (file-exists-p (expand-file-name (file-name-nondirectory tmp-name1) tmp-name5)))= ) @@ -1936,7 +1936,7 @@ tramp--test-backtrace (should-error (copy-file tmp-name4 tmp-name1)) (copy-file tmp-name4 tmp-name1 'ok) (make-directory tmp-name3) - (copy-file tmp-name4 tmp-name3) + (copy-file tmp-name4 (file-name-as-directory tmp-name3)) (should (file-exists-p (expand-file-name (file-name-nondirectory tmp-name4) tmp-name3)))= ) @@ -1975,7 +1975,7 @@ tramp--test-backtrace (should-not (file-exists-p tmp-name1)) (write-region "foo" nil tmp-name1) (make-directory tmp-name3) - (rename-file tmp-name1 tmp-name3) + (rename-file tmp-name1 (file-name-as-directory tmp-name3)) (should-not (file-exists-p tmp-name1)) (should (file-exists-p @@ -2002,7 +2002,7 @@ tramp--test-backtrace (should-not (file-exists-p tmp-name1)) (write-region "foo" nil tmp-name1) (make-directory tmp-name5) - (rename-file tmp-name1 tmp-name5) + (rename-file tmp-name1 (file-name-as-directory tmp-name5)) (should-not (file-exists-p tmp-name1)) (should (file-exists-p @@ -2029,7 +2029,7 @@ tramp--test-backtrace (should-not (file-exists-p tmp-name4)) (write-region "foo" nil tmp-name4 nil 'nomessage) (make-directory tmp-name3) - (rename-file tmp-name4 tmp-name3) + (rename-file tmp-name4 (file-name-as-directory tmp-name3)) (should-not (file-exists-p tmp-name4)) (should (file-exists-p @@ -3464,11 +3464,11 @@ tramp--test-check-files (should (string-equal (buffer-string) elt))) =20 ;; Copy file both directions. - (copy-file file1 tmp-name2) + (copy-file file1 (file-name-as-directory tmp-name2)) (should (file-exists-p file2)) (delete-file file1) (should-not (file-exists-p file1)) - (copy-file file2 tmp-name1) + (copy-file file2 (file-name-as-directory tmp-name1)) (should (file-exists-p file1)) =20 ;; Method "smb" supports `make-symbolic-link' only if the --=20 2.13.4 --------------004A3577E8D9E540D7659E5C-- From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 13 18:44:41 2017 Received: (at control) by debbugs.gnu.org; 13 Aug 2017 22:44:41 +0000 Received: from localhost ([127.0.0.1]:33213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dh1cf-0001O8-98 for submit@debbugs.gnu.org; Sun, 13 Aug 2017 18:44:41 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37302) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dh1cd-0001O0-IT for control@debbugs.gnu.org; Sun, 13 Aug 2017 18:44:39 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2D506160866 for ; Sun, 13 Aug 2017 15:44:34 -0700 (PDT) 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 7bO0I2s6Wbs4 for ; Sun, 13 Aug 2017 15:44:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 82CF8160759 for ; Sun, 13 Aug 2017 15:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 3UFtWgct36rS for ; Sun, 13 Aug 2017 15:44:33 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 69348160734 for ; Sun, 13 Aug 2017 15:44:33 -0700 (PDT) To: control@debbugs.gnu.org From: Paul Eggert Organization: UCLA Computer Science Department Subject: 27986 has a patch Message-ID: <263cba62-dbd2-8b3d-1089-772a21cd90a8@cs.ucla.edu> Date: Sun, 13 Aug 2017 15:44:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) tags 27986 patch From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 13 19:49:11 2017 Received: (at 27986) by debbugs.gnu.org; 13 Aug 2017 23:49:11 +0000 Received: from localhost ([127.0.0.1]:33461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dh2d4-0003m7-Of for submit@debbugs.gnu.org; Sun, 13 Aug 2017 19:49:10 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:41500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dh2d2-0003m1-7A for 27986@debbugs.gnu.org; Sun, 13 Aug 2017 19:49:08 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9D08816086A; Sun, 13 Aug 2017 16:49:02 -0700 (PDT) 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 GHhy8tIB_Hzg; Sun, 13 Aug 2017 16:49:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2C1D316086B; Sun, 13 Aug 2017 16:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 R-B35y2tzxLI; Sun, 13 Aug 2017 16:49:00 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 073B2160734; Sun, 13 Aug 2017 16:49:00 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation From: Paul Eggert To: Philipp References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> Organization: UCLA Computer Science Department Message-ID: <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> Date: Sun, 13 Aug 2017 16:48:59 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> Content-Type: multipart/mixed; boundary="------------B763E56ED065112B24927F91" Content-Language: en-US X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: Eli Zaretskii , 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) This is a multi-part message in MIME format. --------------B763E56ED065112B24927F91 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Getting back to Philipp's original bug report, Apple documentation says m= acOS=20 has a facility like the Linux renameat2 system call (i.e., it's like 'ren= ameat'=20 except it can be told to fail if the destination already exists). Attache= d is a=20 proposed patch to use this facility, which means that the case-insensitiv= ity=20 test would no longer need to be done in macOS. If there's some way to imp= lement=20 renameat_noreplace on MS-Windows we could get rid of the case-insensitivi= ty test=20 there too. I don't have easy access to macOS so I have not installed this patch. It'= d be=20 nice, Philipp, if you could try it out. This patch is independent of the destination-directory patch that I recen= tly=20 proposed in: https://bugs.gnu.org/27986#14 --------------B763E56ED065112B24927F91 Content-Type: text/x-patch; name="0001-Improve-rename-file-behavior-on-macOS.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Improve-rename-file-behavior-on-macOS.patch" =46rom 62605066c4d5a7b91c7800fcc300dbe5082426dc Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 13 Aug 2017 16:31:08 -0700 Subject: [PATCH] Improve rename-file behavior on macOS Problem reported by Philipp Stephani (Bug#27986). * src/fileio.c (Frename_file): Worry about file name case sensitivity only if WINDOWSNT. * src/sysdep.c (renameat_noreplace): Use renameatx_np on macOS, since this provides the necessary atomicity guarantees. --- src/fileio.c | 2 ++ src/sysdep.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/src/fileio.c b/src/fileio.c index 69079c6ae4..ee70dc6e69 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -2259,12 +2259,14 @@ This is what happens in interactive use with M-x.= */) not worry whether NEWNAME exists or whether it is a directory, as it is already another name for FILE. */ bool case_only_rename =3D false; +#ifdef WINDOWSNT if (!NILP (Ffile_name_case_insensitive_p (file))) { newname =3D Fexpand_file_name (newname, Qnil); case_only_rename =3D !NILP (Fstring_equal (Fdowncase (file), Fdowncase (newname))); } +#endif =20 if (!case_only_rename) newname =3D expand_cp_target (Fdirectory_file_name (file), newname);= diff --git a/src/sysdep.c b/src/sysdep.c index 9eb733221e..4e98f1db24 100644 --- a/src/sysdep.c +++ b/src/sysdep.c @@ -2693,6 +2693,8 @@ renameat_noreplace (int srcfd, char const *src, int= dstfd, char const *dst) { #if defined SYS_renameat2 && defined RENAME_NOREPLACE return syscall (SYS_renameat2, srcfd, src, dstfd, dst, RENAME_NOREPLAC= E); +#elif defined RENAME_EXCL + return renameatx_np (srcfd, src, dstfd, dst, RENAME_EXCL); #else errno =3D ENOSYS; return -1; --=20 2.13.4 --------------B763E56ED065112B24927F91-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 09:45:11 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 13:45:11 +0000 Received: from localhost ([127.0.0.1]:35135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhFg7-0003sC-K6 for submit@debbugs.gnu.org; Mon, 14 Aug 2017 09:45:11 -0400 Received: from limerock01.mail.cornell.edu ([128.84.13.241]:40928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhFg6-0003s6-6y for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 09:45:10 -0400 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id v7EDivKQ015919; Mon, 14 Aug 2017 09:44:58 -0400 Received: from [192.168.0.15] (mta-68-175-129-7.twcny.rr.com [68.175.129.7] (may be forged)) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id v7EDiuNc005279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Aug 2017 09:44:57 -0400 Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Paul Eggert , Philipp References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> From: Ken Brown Message-ID: <58da7073-98c3-e7b3-505f-5dcfa2d1a989@cornell.edu> Date: Mon, 14 Aug 2017 09:44:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PMX-Cornell-Gauge: Gauge=XXXXX X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On 8/13/2017 7:48 PM, Paul Eggert wrote: > Getting back to Philipp's original bug report, Apple documentation says > macOS has a facility like the Linux renameat2 system call (i.e., it's > like 'renameat' except it can be told to fail if the destination already > exists). Attached is a proposed patch to use this facility, which means > that the case-insensitivity test would no longer need to be done in > macOS. If there's some way to implement renameat_noreplace on MS-Windows > we could get rid of the case-insensitivity test there too. I think we still need the case-insensitivity test on Cygwin as well as on MS-Windows. Ken From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 11:21:22 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 15:21:22 +0000 Received: from localhost ([127.0.0.1]:35491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhHBC-0004XL-EP for submit@debbugs.gnu.org; Mon, 14 Aug 2017 11:21:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhHBB-0004XF-5e for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 11:21:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhHB2-00080Y-L0 for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 11:21:16 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhHB2-00080O-GO; Mon, 14 Aug 2017 11:21:12 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4331 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dhHB1-0001Wm-TB; Mon, 14 Aug 2017 11:21:12 -0400 Date: Mon, 14 Aug 2017 18:21:07 +0300 Message-Id: <83r2wegopo.fsf@gnu.org> From: Eli Zaretskii To: Ken Brown In-reply-to: <58da7073-98c3-e7b3-505f-5dcfa2d1a989@cornell.edu> (message from Ken Brown on Mon, 14 Aug 2017 09:44:54 -0400) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <58da7073-98c3-e7b3-505f-5dcfa2d1a989@cornell.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, eggert@cs.ucla.edu, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Ken Brown > Date: Mon, 14 Aug 2017 09:44:54 -0400 > Cc: 27986@debbugs.gnu.org > > I think we still need the case-insensitivity test on Cygwin as well as > on MS-Windows. Yes. But I think there are more general issues with this, which I will describe separately. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 11:34:46 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 15:34:47 +0000 Received: from localhost ([127.0.0.1]:35544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhHOA-0004dX-Ll for submit@debbugs.gnu.org; Mon, 14 Aug 2017 11:34:46 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhHO8-0004dR-LQ for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 11:34:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhHO0-0007ns-97 for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 11:34:39 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34509) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhHO0-0007nn-6g; Mon, 14 Aug 2017 11:34:36 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4335 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dhHNz-0004PA-Kv; Mon, 14 Aug 2017 11:34:36 -0400 Date: Mon, 14 Aug 2017 18:34:30 +0300 Message-Id: <83pobygo3d.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert , Ken Brown In-reply-to: <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> (message from Paul Eggert on Sun, 13 Aug 2017 16:48:59 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Paul Eggert > Cc: Eli Zaretskii , 27986@debbugs.gnu.org > Date: Sun, 13 Aug 2017 16:48:59 -0700 > > Getting back to Philipp's original bug report, Apple documentation says macOS > has a facility like the Linux renameat2 system call (i.e., it's like 'renameat' > except it can be told to fail if the destination already exists). Attached is a > proposed patch to use this facility, which means that the case-insensitivity > test would no longer need to be done in macOS. If there's some way to implement > renameat_noreplace on MS-Windows we could get rid of the case-insensitivity test > there too. There's nothing easier than implementing renameat_noreplace on MS-Windows, since the underlying system call does that by default, and it's emulating the Posix behavior that requires complications. In fact, we already have this implementation: see sys_rename_replace (in w32.c) which needs to be called with its last argument FALSE (modulo the "at" part, which is easily handled). (Ken, what about Cygwin?) So I think we may be able to remove the case-sensitivity check right now. And in any case, that check should be in barf_or_query_if_file_exists anyway, because renameat_noreplace on case-insensitive filesystems already supports renaming to a different letter-case. The reason we had this check before is because we didn't employ renameat_noreplace, but called 'rename' right away, and that needed a question before overwriting the target. But now renameat_noreplace will silently succeed to rename when the user wants to only change the letter-case, so no such check is needed. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 11:40:54 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 15:40:54 +0000 Received: from localhost ([127.0.0.1]:35576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhHU6-0004gd-Fi for submit@debbugs.gnu.org; Mon, 14 Aug 2017 11:40:54 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48685) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhHU4-0004gX-6h for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 11:40:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhHTv-0001wX-Ko for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 11:40:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhHTv-0001vm-3D; Mon, 14 Aug 2017 11:40:43 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4343 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dhHTu-0001kD-Fw; Mon, 14 Aug 2017 11:40:42 -0400 Date: Mon, 14 Aug 2017 18:40:37 +0300 Message-Id: <83o9rignt6.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <1002ee73-0ab5-409b-831f-0c283c322264@cs.ucla.edu> (message from Paul Eggert on Sun, 13 Aug 2017 15:42:05 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <1002ee73-0ab5-409b-831f-0c283c322264@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Paul Eggert > Cc: Philipp , 27986@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. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 12:34:14 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 16:34:14 +0000 Received: from localhost ([127.0.0.1]:35798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIJi-00055W-DE for submit@debbugs.gnu.org; Mon, 14 Aug 2017 12:34:14 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIJh-00055Q-H9 for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 12:34:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhIJX-0002lq-A2 for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 12:34:08 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhIJX-0002lW-6p; Mon, 14 Aug 2017 12:34:03 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4573 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dhIJW-0001PD-JD; Mon, 14 Aug 2017 12:34:03 -0400 Date: Mon, 14 Aug 2017 19:33:57 +0300 Message-Id: <83mv72glca.fsf@gnu.org> From: Eli Zaretskii To: eggert@cs.ucla.edu In-reply-to: <83pobygo3d.fsf@gnu.org> (message from Eli Zaretskii on Mon, 14 Aug 2017 18:34:30 +0300) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <83pobygo3d.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org, kbrown@cornell.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Mon, 14 Aug 2017 18:34:30 +0300 > From: Eli Zaretskii > Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org > > There's nothing easier than implementing renameat_noreplace on > MS-Windows, since the underlying system call does that by default, and > it's emulating the Posix behavior that requires complications. In > fact, we already have this implementation: see sys_rename_replace (in > w32.c) which needs to be called with its last argument FALSE (modulo > the "at" part, which is easily handled). Which I just did. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 12:50:50 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 16:50:50 +0000 Received: from localhost ([127.0.0.1]:35883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIZm-0005D3-7V for submit@debbugs.gnu.org; Mon, 14 Aug 2017 12:50:50 -0400 Received: from mail-oi0-f53.google.com ([209.85.218.53]:33067) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIZl-0005Cx-DK for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 12:50:49 -0400 Received: by mail-oi0-f53.google.com with SMTP id f11so89248731oic.0 for <27986@debbugs.gnu.org>; Mon, 14 Aug 2017 09:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lmiz5aayluSWdeK1TsC5EY0RfTzp1qWkOWbuCyLepzs=; b=qG+bAFVA2JcF+luQ3zB5K4nC+68/kmJUd8LKKpHCSExyy1PzcKQN8/10DHLN9vAm+C a7cvobvinfis7+kv6wXn5dbXj3k/21a8fIDN1/7cP30coOivZt+5AbELdjq/seLmA08/ RoadN2IE1Vxkf22dzanz0UPGI335BT7/HCoDdpTLyQzeKecbcPRbk756xg+lNAkTYHiX uOzvpSQaHXECeek9VBzqE1JEyPFjwvLGgQcaFVWLB2+t+P4KlxIvVd5LqK7ZEfdeCcaf 2rkrND4ERNyu6fGFv9HzHS7E8QTgY6sZskvGAik6kcuu2TRndWXTJrcm9TOeqFSiOBP/ 6zZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lmiz5aayluSWdeK1TsC5EY0RfTzp1qWkOWbuCyLepzs=; b=t1+jHHd9k46FMuJqfmqckD/GeOQvrb6BEFVx4DQ9AvxNXH7p6B5s4UGkdR0L4H63Q6 mEWaHScR9zoThJX7Rek1gCw7D7V+E9BNmT6cL5qJDncq2neQZAtQEcBwjl9M4cvdEIK+ SbbZCtbZCEMJqgmmL4CQi0XqC5LKC9PYEvtjz4Kt/BIbNGn3oqqMgjR6SunspjvCdElb 327e+fWG68Py0FTxtptrlnvMd/c98sXKQ2iX63UgRW/1pSe/MmPx19Dpn/nvPxPQMBQi P1sKoBwsu9xoCQxQoqEhnpCs8ixDOpPvJQ7b/8TYT+GYpXCxlU+LG417U7kkGs7DAt9m CDzA== X-Gm-Message-State: AHYfb5gyfrSJeJFZoSRNdGSbIjSv7432lj1zt3Tcp/hZKgy2N8o1pSrX ZSHt1UeYUO23Y9ufIAwkClIXEjEWnA== X-Received: by 10.202.208.144 with SMTP id j16mr30291943oiy.82.1502729443491; Mon, 14 Aug 2017 09:50:43 -0700 (PDT) MIME-Version: 1.0 References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> In-Reply-To: <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> From: Philipp Stephani Date: Mon, 14 Aug 2017 16:50:33 +0000 Message-ID: Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Paul Eggert Content-Type: multipart/alternative; boundary="001a1143b6f2ac424f0556b97618" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 27986 Cc: Eli Zaretskii , 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a1143b6f2ac424f0556b97618 Content-Type: text/plain; charset="UTF-8" Paul Eggert schrieb am Mo., 14. Aug. 2017 um 01:49 Uhr: > Getting back to Philipp's original bug report, Apple documentation says > macOS > has a facility like the Linux renameat2 system call (i.e., it's like > 'renameat' > except it can be told to fail if the destination already exists). Attached > is a > proposed patch to use this facility, which means that the > case-insensitivity > test would no longer need to be done in macOS. If there's some way to > implement > renameat_noreplace on MS-Windows we could get rid of the > case-insensitivity test > there too. > > I don't have easy access to macOS so I have not installed this patch. It'd > be > nice, Philipp, if you could try it out. > > Thanks, the patch fixes the problem. However, it's still not 100% correct: now casing changes such as from "A" to "a" where macOS treats the file names as equivalent trigger the "file already exists" signal as well. I don't think that can be fixed, though; there's no way to special-case casing changes while keeping atomicity intact. So I'd rather have Emacs react conservatively and skip the casing check entirely. Note that the manpage says: RENAME_EXCL On file systems that support it (see getattrlist(2) VOL_CAP_INT_RENAME_EXCL), it will cause EEXIST to be returned if the destination already exists. I interpret this such that if the filesystem doesn't support RENAME_EXCL the rename will succeed even if the destination exists. Since we probably won't be able to solve all issues across operating systems and filesystems, probably we should have at least a warning in the documentation that rename-file attempts to be race-free and atomic, but only on a best-effort basis. --001a1143b6f2ac424f0556b97618 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Mo., 14. Aug. 2017 um 01:49=C2=A0Uhr:
Getting back to Philipp's original bug report, Apple docu= mentation says macOS
has a facility like the Linux renameat2 system call (i.e., it's like &#= 39;renameat'
except it can be told to fail if the destination already exists). Attached = is a
proposed patch to use this facility, which means that the case-insensitivit= y
test would no longer need to be done in macOS. If there's some way to i= mplement
renameat_noreplace on MS-Windows we could get rid of the case-insensitivity= test
there too.

I don't have easy access to macOS so I have not installed this patch. I= t'd be
nice, Philipp, if you could try it out.


Thanks, the patch fixes the problem. H= owever, it's still not 100% correct: now casing changes such as from &q= uot;A" to "a" where macOS treats the file names as equivalen= t trigger the "file already exists" signal as well. I don't t= hink that can be fixed, though; there's no way to special-case casing c= hanges while keeping atomicity intact. So I'd rather have Emacs react c= onservatively and skip the casing check entirely.
Note that the m= anpage says:

RENAME_EXCL =C2=A0 On file systems= that support it (see getattrlist(2) VOL_CAP_INT_RENAME_EXCL), it will caus= e EEXIST to be=C2= =A0returned if the destination already exists.=C2=A0

I interpret this such that if the filesystem doesn't su= pport RENAME_EXCL the rename will succeed even if the destination exists.

Since we probably won't be able to solve = all issues across operating systems and filesystems, probably we should hav= e at least a warning in the documentation that rename-file attempts to be r= ace-free and atomic, but only on a best-effort basis.

--001a1143b6f2ac424f0556b97618-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 12:58:22 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 16:58:22 +0000 Received: from localhost ([127.0.0.1]:35913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIh4-0005Fq-48 for submit@debbugs.gnu.org; Mon, 14 Aug 2017 12:58:22 -0400 Received: from mail-oi0-f45.google.com ([209.85.218.45]:34673) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIh2-0005Fk-B5 for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 12:58:20 -0400 Received: by mail-oi0-f45.google.com with SMTP id x3so89623595oia.1 for <27986@debbugs.gnu.org>; Mon, 14 Aug 2017 09:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yYhtth6errfNDJz2MSn+pg/55IdlvbTbEjlBbfiMGmk=; b=MgMMxdUljGfuMdpQlGOXAFlK5msHYMcHqvSFkwE79TGp/uPDBf0LBTJPIPbUNQcGSi xLSGWkFfN8LARj5QGsLJ6tFNS88oT+KdGoLKZ3buvUcjQR/fa5KDoxAa8CZ0wNdWgO9H UVIeRG7AQhPJ2/IW/M903qntwQCP0nczPq2EOsANwjnyZJ3RDjEpeFHsROUiOeZhhf2Y IBNHKpSXnfVwssUf+WP4lnZF9bP9hPexdz/8rESXBY3VwPK/jCLKUwTZPIp2t4Kllw5G zrg1ymPxWlQpOlI1ibvHXilysihJ0oPRQI23TxFudASFM8YIoOrKprFyVFUavU1HhbJd kjsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yYhtth6errfNDJz2MSn+pg/55IdlvbTbEjlBbfiMGmk=; b=H8gStFf38h2h9EPZ94rgvXbz2EjRjB6JihBAzsZdX4YFzYWbtohsVS91rzooW6TCr0 7v4kS7ZLUQJ+fe4pTJC0WyepP7oKa9+ibDt5YXRe6dlXjdAhtenYscVasKniKOUIZWLI EwRdani03VNMU0kIzNDeha6fwOGVGUcqpbjQ+jhDXBt8FDByw0GN3kzPKwehe1lCA6Au ReMkhx0yc0k8If1NKE6spJgZ8HbmV0WMQSMT9m5EBNKkwld6GLzfh1KYuI2sHws2gwMf dLfLYXU7wgpe/iRCB6Nj3lZ7fykejlE5UknNyUg3O/3/dnjaOuV3es54ab9CaULq5vwS O9AQ== X-Gm-Message-State: AHYfb5hRIWrjF5OSLIICfzcYCBO+ElEn9yifjYYzWgt4Fr06oQtz9goY vNFIFwwqyZjDeER3ozkDSPSUaSm84Q== X-Received: by 10.202.4.208 with SMTP id 199mr26949854oie.182.1502729894610; Mon, 14 Aug 2017 09:58:14 -0700 (PDT) MIME-Version: 1.0 References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <83pobygo3d.fsf@gnu.org> In-Reply-To: <83pobygo3d.fsf@gnu.org> From: Philipp Stephani Date: Mon, 14 Aug 2017 16:58:04 +0000 Message-ID: Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii , Paul Eggert , Ken Brown Content-Type: multipart/alternative; boundary="001a11c033d68fcb030556b9915a" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) --001a11c033d68fcb030556b9915a Content-Type: text/plain; charset="UTF-8" Eli Zaretskii schrieb am Mo., 14. Aug. 2017 um 17:34 Uhr: > > From: Paul Eggert > > Cc: Eli Zaretskii , 27986@debbugs.gnu.org > > Date: Sun, 13 Aug 2017 16:48:59 -0700 > > > > Getting back to Philipp's original bug report, Apple documentation says > macOS > > has a facility like the Linux renameat2 system call (i.e., it's like > 'renameat' > > except it can be told to fail if the destination already exists). > Attached is a > > proposed patch to use this facility, which means that the > case-insensitivity > > test would no longer need to be done in macOS. If there's some way to > implement > > renameat_noreplace on MS-Windows we could get rid of the > case-insensitivity test > > there too. > > There's nothing easier than implementing renameat_noreplace on > MS-Windows, since the underlying system call does that by default, and > it's emulating the Posix behavior that requires complications. > You might be able to eliminate these complications by calling MoveFileExW with MOVEFILE_REPLACE_EXISTING. --001a11c033d68fcb030556b9915a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Mo., 14. Aug. 2017 um 17:34=C2=A0Uhr:
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: Eli Zaretskii <eliz@gnu.org>, 27986@debbugs.gnu.org
> Date: Sun, 13 Aug 2017 16:48:59 -0700
>
> Getting back to Philipp's original bug report, Apple documentation= says macOS
> has a facility like the Linux renameat2 system call (i.e., it's li= ke 'renameat'
> except it can be told to fail if the destination already exists). Atta= ched is a
> proposed patch to use this facility, which means that the case-insensi= tivity
> test would no longer need to be done in macOS. If there's some way= to implement
> renameat_noreplace on MS-Windows we could get rid of the case-insensit= ivity test
> there too.

There's nothing easier than implementing renameat_noreplace on
MS-Windows, since the underlying system call does that by default, and
it's emulating the Posix behavior that requires complications.

You might be able to eliminate these complicati= ons by calling MoveFileExW with MOVEFILE_REPLACE_EXISTING.
--001a11c033d68fcb030556b9915a-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 13:04:35 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 17:04:35 +0000 Received: from localhost ([127.0.0.1]:35942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIn4-0005Jj-RT for submit@debbugs.gnu.org; Mon, 14 Aug 2017 13:04:35 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIn2-0005Jc-SH for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 13:04:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhImu-0002d5-JN for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 13:04:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhImu-0002d1-Gr; Mon, 14 Aug 2017 13:04:24 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4798 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dhImu-000354-03; Mon, 14 Aug 2017 13:04:24 -0400 Date: Mon, 14 Aug 2017 20:04:18 +0300 Message-Id: <83lgmmgjxp.fsf@gnu.org> From: Eli Zaretskii To: Philipp Stephani In-reply-to: (message from Philipp Stephani on Mon, 14 Aug 2017 16:58:04 +0000) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <83pobygo3d.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: eggert@cs.ucla.edu, 27986@debbugs.gnu.org, kbrown@cornell.edu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Philipp Stephani > Date: Mon, 14 Aug 2017 16:58:04 +0000 > Cc: 27986@debbugs.gnu.org > > There's nothing easier than implementing renameat_noreplace on > MS-Windows, since the underlying system call does that by default, and > it's emulating the Posix behavior that requires complications. > > You might be able to eliminate these complications by calling MoveFileExW with > MOVEFILE_REPLACE_EXISTING. Thanks, but I see no need, because using that function doesn't solve any problems we have (it isn't guaranteed to be atomic if the destination exists), and adds new complexity (because it won't move files across volumes, and because it didn't exist before XP). The "complications" I mentioned above are already implemented and well tested, so I see no point in eliminating them. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 13:09:53 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 17:09:53 +0000 Received: from localhost ([127.0.0.1]:35966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIsD-0005M4-Er for submit@debbugs.gnu.org; Mon, 14 Aug 2017 13:09:53 -0400 Received: from mail-oi0-f51.google.com ([209.85.218.51]:35142) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhIsC-0005Ly-4I for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 13:09:52 -0400 Received: by mail-oi0-f51.google.com with SMTP id e124so90098490oig.2 for <27986@debbugs.gnu.org>; Mon, 14 Aug 2017 10:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vl5vFeLhGgjDAyBh22q0NlPJ/7cfdkV4jC1wHDIZVwI=; b=YyrJrrvN+FvDi5KmGI64uz0jljsPRJAiuBLq6Oh/RTScW9xMD7V4AUgmcTb3JFKtuK t0flzi78FQ5vWiOIqm5zd19D2o+bpbqcnHntXHU1VVvYO7pHAnpb8MVMzpG74jj9BloP ojFtMLWoIaMKuVq5YNYYpyuppg/E4rLzpAr8VzH5p5HTB5zAkaFqAnxfmiLu7P8FeCLE 7Fy/nR98D5g5byQDSqOmkKIX2e+urc3oRB05foeJqDIyg2ElpgMvy9Y8nHIQd3q5pZ8P c+rNV/il5VP5Ah0ojn+hK7QvqD6x9RdweNRgVlJn4qhwmaNEffCnbtHAgvAfk9kUAKj8 L+FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vl5vFeLhGgjDAyBh22q0NlPJ/7cfdkV4jC1wHDIZVwI=; b=FPD2IOxS+oJ8HPzVnD01nqM2VKBhzbYeizChby82z8vjo/8HmKGLpiHyntmQwq3lGL BymXpNCa8bAPqVrAQQWgqIvDHSOC7D0kfbl3k9YkMiUEtuJqbn9aAXpFqZHpLmAVrw1U C+uNouaZ2vWAQ+bw+JVyS22rSFqT04XNIKX5tNgGHd4nYd3nFi/+XUnwE4Zg2Q8ogxtK znea8unua32CsPgW0GvWee9JvE+mloCojgvlYwnmG9R4TVNLt4uQAN+GJTbjCrhOy0F+ JMmH/3VbOuMQrrxszuewydA89qGpziNDtTZiKRMZD4GhSAB6ZhR76X4cXLQX+KA9PXGe Tj4w== X-Gm-Message-State: AHYfb5iY6nitQjJHJBWPcQxxTeEnOzW5lyANlkNDxot60jpObAD4fCCt BQ4C0o/X4cHdF8xFdibxUpX5DYzbCQ== X-Received: by 10.202.208.144 with SMTP id j16mr30375051oiy.82.1502730586293; Mon, 14 Aug 2017 10:09:46 -0700 (PDT) MIME-Version: 1.0 References: <83poc8tynu.fsf@gnu.org> In-Reply-To: <83poc8tynu.fsf@gnu.org> From: Philipp Stephani Date: Mon, 14 Aug 2017 17:09:35 +0000 Message-ID: Subject: Re: bug#27986: 26.0.50; `rename-file' can rename files without confirmation To: Eli Zaretskii Content-Type: multipart/alternative; boundary="001a1143b6f2ca0ca40556b9ba63" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) --001a1143b6f2ca0ca40556b9ba63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eli Zaretskii schrieb am So., 6. Aug. 2017 um 19:05 Uhr: > > From: Philipp > > Date: Sun, 06 Aug 2017 17:40:18 +0200 > > > > (rename-file "/tmp/emacs/=E1=BA=9E" "/tmp/emacs/=C3=9F") > > nil > > > > Note how `rename-file' has silently overwritten `=C3=9F'. This is beca= use on > > macOS, `=C3=9F' and `=E1=BA=9E' are different file names, but Emacs tre= ats them as > > equal. Probably the test for case-insensitive file names should be > > removed altogether > > Which one? there are two of them. > I guess all of them where correctness would depend on the outcome. > > > (it can't work correctly and introduces a filesystem race) > > It cannot work correctly _because_ of a possible race or because of > some other reasons? If the latter, please elaborate. As this example shows, there are cases where two case-insensitive filenames are considered equivalent by Emacs, but different by the actual filesystem. This is unavoidable, because the definition of "case-insensitive" changes all the time, both in Emacs and in the filesystems. Generally it's impossible to detect whether two filenames would refer to the same file without actually creating the file. And even then the answer depends on how the file is created, see e.g. FILE_FLAG_POSIX_SEMANTICS. So Emacs can't compare filenames and make decisions based on the result upon which the correctness of a critical function depends. Comparing filenames can still be OK for best-effort attempts at giving the user better error messages or similar. > If the former, > then at least on MS-Windows we have a race anyway, because the > underlying system APIs are not atomic. Wouldn't MoveFileExW with MOVE_FILE_REPLACE_EXISTING be atomic? > and `rename-file' should use link(2) + unlink(2) if renameat2 > > isn't available. > > 'link' and 'unlink' accept strings as arguments, not integer numbers > such as 2. > Yes, I mean the functions described in section 2 of the man page. link(2) is a common markup for this. > > More to the point, how can this strategy work on a case-insensitive > filesystem? What am I missing? > IIUC link(2) + unlink(2) would, if successful, guarantee enough atomicity in the sense that the old file is now guaranteed to be the new file, and the call is guaranteed to fail if the new file already exists. I don't think anything can help with the case-changing problem; I think we just have to live with an occasional false positive signal in this case. --001a1143b6f2ca0ca40556b9ba63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= So., 6. Aug. 2017 um 19:05=C2=A0Uhr:
> From: Philipp <p.stephani2@gmail.com>
> Date: Sun, 06 Aug 2017 17:40:18 +0200
>
> (rename-file "/tmp/emacs/=E1=BA=9E" "/tmp/emacs/=C3=9F&= quot;)
> nil
>
> Note how `rename-file' has silently overwritten `=C3=9F'.=C2= =A0 This is because on
> macOS, `=C3=9F' and `=E1=BA=9E' are different file names, but = Emacs treats them as
> equal.=C2=A0 Probably the test for case-insensitive file names should = be
> removed altogether

Which one? there are two of them.

I gue= ss all of them where correctness would depend on the outcome.
=C2= =A0

> (it can't work correctly and introduces a filesystem race)

It cannot work correctly _because_ of a possible race or because of
some other reasons?=C2=A0 If the latter, please elaborate.=C2=A0

As this example shows, there are cases where two case= -insensitive filenames are considered equivalent by Emacs, but different by= the actual filesystem. This is unavoidable, because the definition of &quo= t;case-insensitive" changes all the time, both in Emacs and in the fil= esystems. Generally it's impossible to detect whether two filenames wou= ld refer to the same file without actually creating the file. And even then= the answer depends on how the file is created, see e.g. FILE_FLAG_POSIX_SE= MANTICS. So Emacs can't compare filenames and make decisions based on t= he result upon which the correctness of a critical function depends. Compar= ing filenames can still be OK for best-effort attempts at giving the user b= etter error messages or similar.
=C2=A0
If the former,
then at least on MS-Windows we have a race anyway, because the
underlying system APIs are not atomic.

Woul= dn't MoveFileExW with MOVE_FILE_REPLACE_EXISTING be atomic?
<= br>
> and `rename-file' should use link(2) + unlink(2) if renameat2
> isn't available.

'link' and 'unlink' accept strings as arguments, not intege= r numbers
such as 2.

Yes, I mean the functions de= scribed in section 2 of the man page. link(2) is a common markup for this.<= /div>
=C2=A0

More to the point, how can this strategy work on a case-insensitive
filesystem?=C2=A0 What am I missing?

II= UC link(2) + unlink(2) would, if successful, guarantee enough atomicity in = the sense that the old file is now guaranteed to be the new file, and the c= all is guaranteed to fail if the new file already exists. I don't think= anything can help with the case-changing problem; I think we just have to = live with an occasional false positive signal in this case.=C2=A0
--001a1143b6f2ca0ca40556b9ba63-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 13:22:28 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 17:22:28 +0000 Received: from localhost ([127.0.0.1]:36018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhJ4N-0005S9-ON for submit@debbugs.gnu.org; Mon, 14 Aug 2017 13:22:27 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56491) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhJ4M-0005S3-1x for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 13:22:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhJ4B-0003UK-VF for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 13:22:20 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhJ4B-0003UE-Rc; Mon, 14 Aug 2017 13:22:15 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4832 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dhJ4B-0001C8-9s; Mon, 14 Aug 2017 13:22:15 -0400 Date: Mon, 14 Aug 2017 20:22:10 +0300 Message-Id: <83k226gj3x.fsf@gnu.org> From: Eli Zaretskii To: Philipp Stephani In-reply-to: (message from Philipp Stephani on Mon, 14 Aug 2017 17:09:35 +0000) Subject: Re: bug#27986: 26.0.50; `rename-file' can rename files without confirmation References: <83poc8tynu.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Philipp Stephani > Date: Mon, 14 Aug 2017 17:09:35 +0000 > Cc: 27986@debbugs.gnu.org > > > Note how `rename-file' has silently overwritten `ß'. This is because on > > macOS, `ß' and `ẞ' are different file names, but Emacs treats them as > > equal. Probably the test for case-insensitive file names should be > > removed altogether > > Which one? there are two of them. > > I guess all of them where correctness would depend on the outcome. But then we lose a feature which just a few releases ago was deemed valuable enough to have. > As this example shows, there are cases where two case-insensitive filenames are considered equivalent by > Emacs, but different by the actual filesystem. This is unavoidable, because the definition of "case-insensitive" > changes all the time, both in Emacs and in the filesystems. Generally it's impossible to detect whether two > filenames would refer to the same file without actually creating the file. Wouldn't trying to rename it actually tell you that, by failing with EEXIST? (On Windows, it simply succeeds and changes the letter-case silently, but I understand that is not what happens on macOS.) > If the former, > then at least on MS-Windows we have a race anyway, because the > underlying system APIs are not atomic. > > Wouldn't MoveFileExW with MOVE_FILE_REPLACE_EXISTING be atomic? No, it isn't guaranteed to be atomic. No documentation says that, certainly not any official documentation. If I had access to the sources, I could have looked there, but I don't. Failing that, my assumption is that it isn't atomic, because meta-data of more than one file needs to be touched in this case. > Yes, I mean the functions described in section 2 of the man page. link(2) is a common markup for this. My point was that GNU coding standards frown on use of such markup. > More to the point, how can this strategy work on a case-insensitive > filesystem? What am I missing? > > IIUC link(2) + unlink(2) would, if successful, guarantee enough atomicity in the sense that the old file is now > guaranteed to be the new file, and the call is guaranteed to fail if the new file already exists. I actually think that if the old and the new name are equal but for the letter-case, and the filesystem is case-insensitive, doing that will delete the file, so you are left with nothing. > I don't think anything can help with the case-changing problem; I > think we just have to live with an occasional false positive signal > in this case. That'd be an unfortunate regression, IMO. It isn't right for us to back out changes we just introduced, which were considered important when we did that. We ought to find a solution that doesn't remove this feature, not even on macOS. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 19:03:26 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 23:03:26 +0000 Received: from localhost ([127.0.0.1]:37482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhOOM-0001ZX-6P for submit@debbugs.gnu.org; Mon, 14 Aug 2017 19:03:26 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhOOK-0001ZR-9c for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 19:03:24 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 651F81600B5; Mon, 14 Aug 2017 16:03:18 -0700 (PDT) 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 EUIhniDVERsK; Mon, 14 Aug 2017 16:03:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8028516083A; Mon, 14 Aug 2017 16:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 P8fJKZ3Q5RKz; Mon, 14 Aug 2017 16:03:17 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 571A3160804; Mon, 14 Aug 2017 16:03:17 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Philipp Stephani References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> Date: Mon, 14 Aug 2017 16:03:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------71DD1EB27FBD50BE6ED2022A" Content-Language: en-US X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: Eli Zaretskii , 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) This is a multi-part message in MIME format. --------------71DD1EB27FBD50BE6ED2022A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Philipp Stephani wrote: > there's no way to special-case > casing changes while keeping atomicity intact. So I'd rather have Emacs > react conservatively and skip the casing check entirely. Yes, that makes sense, at least for macOS. > Note that the manpage says: >=20 > RENAME_EXCL On file systems that support it (see getattrlist(2) > VOL_CAP_INT_RENAME_EXCL), it will cause EEXIST to be returned if the > destination already exists. >=20 > I interpret this such that if the filesystem doesn't support RENAME_EXC= L > the rename will succeed even if the destination exists. I interpret it to mean that if the filesystem doesn't support RENAME_EXCL= , the=20 rename will fail with errno =3D=3D EINVAL or ENOSYS. At least, that's ho= w it works=20 under GNU/Linux. If it behaved the way you suggest, there'd be no good wa= y to=20 emulate RENAME_EXCL on filesystems lacking it, which would surely not be = Apple's=20 intent. Please check this, though. I installed the patch on 'master' to help you = do that. Now that renameat_noreplace works on DOS_NT, would it make sense to apply= the=20 attached further patch as well? If we can get renameat_noreplace to work = on=20 Cygwin the we could simplify the fileio.c code even further. > Since we probably won't be able to solve all issues across operating > systems and filesystems, probably we should have at least a warning in = the > documentation that rename-file attempts to be race-free and atomic, but > only on a best-effort basis. True. I'd like to get the directory issue fixed before worrying about thi= s,=20 though. (That way I don't have to document the security holes in the curr= ent=20 implementation. :-) I'll follow up separately about that. --------------71DD1EB27FBD50BE6ED2022A Content-Type: text/x-patch; name="0001-Improve-rename-file-behavior-on-DOS_NT.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Improve-rename-file-behavior-on-DOS_NT.patch" =46rom c929fb0ed882f15e492caff9f6610c87a57bca9a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 14 Aug 2017 15:59:37 -0700 Subject: [PATCH] Improve rename-file behavior on DOS_NT See Bug#27986. * src/fileio.c (Frename_file): Do not worry about file name case sensitivity if DOS_NT, since renameat_noreplace should work in that case. --- src/fileio.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/src/fileio.c b/src/fileio.c index 9f6de5b6ca..f5000352ab 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -2254,12 +2254,13 @@ This is what happens in interactive use with M-x.= */) =20 file =3D Fexpand_file_name (file, Qnil); =20 - /* If the filesystem is case-insensitive and the file names are - identical but for case, treat it as a change-case request, and do - not worry whether NEWNAME exists or whether it is a directory, as - it is already another name for FILE. */ + /* If renameat_noreplace does not work and the filesystem is + case-insensitive and the file names are identical but for case, + treat it as a change-case request, and do not worry whether + NEWNAME exists or whether it is a directory, as it is already + another name for FILE. */ bool case_only_rename =3D false; -#if defined CYGWIN || defined DOS_NT +#ifdef CYGWIN if (!NILP (Ffile_name_case_insensitive_p (file))) { newname =3D Fexpand_file_name (newname, Qnil); --=20 2.13.5 --------------71DD1EB27FBD50BE6ED2022A-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 19:31:46 2017 Received: (at 27986) by debbugs.gnu.org; 14 Aug 2017 23:31:46 +0000 Received: from localhost ([127.0.0.1]:37495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhOpm-0001n0-Ad for submit@debbugs.gnu.org; Mon, 14 Aug 2017 19:31:46 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58536) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhOpk-0001mu-Og for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 19:31:45 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3667B160753; Mon, 14 Aug 2017 16:31:39 -0700 (PDT) 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 MLSGsf1gNY0K; Mon, 14 Aug 2017 16:31:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 643F716074C; Mon, 14 Aug 2017 16:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 cED6RrLXQwgn; Mon, 14 Aug 2017 16:31:38 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 412831600B5; Mon, 14 Aug 2017 16:31:38 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <1002ee73-0ab5-409b-831f-0c283c322264@cs.ucla.edu> <83o9rignt6.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Mon, 14 Aug 2017 16:31:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83o9rignt6.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii wrote: > 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? Currently (rename-file A B) requires at least two system calls to work: o= ne to=20 test whether B is a directory, and the other to actually do the rename. T= his=20 leads to race conditions if other actors change the file system between t= he two=20 calls. For example, suppose a victim is about to execute (rename-file "/tmp/foo"= =20 "/tmp/bar" t), and suppose an attacker wants to destroy the victim's file= =20 /home/victim/secret/foo. The attacker can do (make-symbolic-link=20 "/home/victim/secret" "/tmp/bar"), and this will cause the victim to lose= all=20 the data in /home/victim/secret/bar even though the attacker is supposed = to lack=20 access to anything under /home/victim/secret. I doubt whether this is the= only=20 such scenario; it's just the first one that popped into my mind. As icing on the cake, the current behavior of (rename-file A B) disagrees= with=20 its documentation when B is an existing directory. There is no good solution to this problem. All solutions are bad, in that= either=20 they are not 100% backward compatible with existing behavior, or they con= tinue=20 to encourage insecure Elisp code. The proposed patch attempts to choose t= he=20 least bad way forward, by making the default behavior more secure, at a=20 relatively minor cost in compatibility. Most uses of rename-file etc. won= 't care=20 about the change, and the ones that do care are likely to have security p= roblems=20 anyway. The proposed solution improves security, because a common pattern in Lisp= code=20 when creating a file BAR "atomically" is to create and write a temporary = file=20 FOO and then execute (rename-file FOO BAR). Currently, this approach can = be=20 attacked in the way described when BAR's parent directory is /tmp or any = similar=20 directory. With the proposed patch, this approach cannot be hijacked in t= his=20 way, because BAR will be a file name and not a directory name. That is, t= he call=20 to rename-file will specify whether the destination-directory semantics a= re=20 desired, rather than relying on the state of the filesystem to specify it= . This=20 is more secure because the state of the filesystem is partially under con= trol of=20 attackers. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 21:19:37 2017 Received: (at 27986) by debbugs.gnu.org; 15 Aug 2017 01:19:37 +0000 Received: from localhost ([127.0.0.1]:37547 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhQW9-0006H9-7U for submit@debbugs.gnu.org; Mon, 14 Aug 2017 21:19:37 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhQW6-0006H3-Uk for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 21:19:35 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 46C241600B5; Mon, 14 Aug 2017 18:19:28 -0700 (PDT) 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 bMlSMXtuvhBi; Mon, 14 Aug 2017 18:19:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1E53B1600CF; Mon, 14 Aug 2017 18:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 vsq5Ksew56XD; Mon, 14 Aug 2017 18:19:27 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E1DDD1600B5; Mon, 14 Aug 2017 18:19:26 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation From: Paul Eggert To: Philipp Stephani References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> Organization: UCLA Computer Science Department Message-ID: <4dfc78db-b550-4cc6-efad-67b7c57c3cce@cs.ucla.edu> Date: Mon, 14 Aug 2017 18:19:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> Content-Type: multipart/mixed; boundary="------------15214F29F7C6BD4104BC5CED" Content-Language: en-US X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: Eli Zaretskii , 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) This is a multi-part message in MIME format. --------------15214F29F7C6BD4104BC5CED Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Paul Eggert wrote: > I installed the patch on 'master' to help you do that. After rereading the Apple manual I installed the attached further patch into master, so please try updating to the latest master before testing. --------------15214F29F7C6BD4104BC5CED Content-Type: text/x-patch; name="0001-Improve-rename-file-port-to-macOS.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Improve-rename-file-port-to-macOS.patch" >From 97460582e2d0052f27d342ddb90309dc3da700b8 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 14 Aug 2017 18:16:04 -0700 Subject: [PATCH] Improve rename-file port to macOS * src/fileio.c (Frename_file): On macOS, renameat_noreplace can fail with errno == ENOTSUP on file systems where it is not supported, according to the Apple documentation. --- src/fileio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/fileio.c b/src/fileio.c index 9f6de5b..e557483 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -2297,7 +2297,7 @@ This is what happens in interactive use with M-x. */) rename_errno = errno; switch (rename_errno) { - case EEXIST: case EINVAL: case ENOSYS: + case EEXIST: case EINVAL: case ENOSYS: case ENOTSUP: barf_or_query_if_file_exists (newname, rename_errno == EEXIST, "rename to it", INTEGERP (ok_if_already_exists), -- 2.7.4 --------------15214F29F7C6BD4104BC5CED-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 22:36:05 2017 Received: (at 27986) by debbugs.gnu.org; 15 Aug 2017 02:36:05 +0000 Received: from localhost ([127.0.0.1]:37568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhRi9-0006rs-Ct for submit@debbugs.gnu.org; Mon, 14 Aug 2017 22:36:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53253) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhRi8-0006rV-4r for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 22:36:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhRhz-0002Uu-WB for 27986@debbugs.gnu.org; Mon, 14 Aug 2017 22:35:59 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48479) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhRhz-0002Uq-SO; Mon, 14 Aug 2017 22:35:55 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1234 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dhRhz-00063E-A2; Mon, 14 Aug 2017 22:35:55 -0400 Date: Tue, 15 Aug 2017 05:35:51 +0300 Message-Id: <83efsdh81k.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> (message from Paul Eggert on Mon, 14 Aug 2017 16:03:13 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: Eli Zaretskii , 27986@debbugs.gnu.org > From: Paul Eggert > Date: Mon, 14 Aug 2017 16:03:13 -0700 > > Philipp Stephani wrote: > > > there's no way to special-case > > casing changes while keeping atomicity intact. So I'd rather have Emacs > > react conservatively and skip the casing check entirely. > > Yes, that makes sense, at least for macOS. As I wrote, we should not lose the feature that renaming a file on macOS to a different letter-case works without nagging the user with confirmations. I don't think this runs afoul of security, since the letter-case check doesn't break atomicity in any way. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 03:00:58 2017 Received: (at 27986) by debbugs.gnu.org; 15 Aug 2017 07:00:58 +0000 Received: from localhost ([127.0.0.1]:37654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhVqU-0000Vy-Ly for submit@debbugs.gnu.org; Tue, 15 Aug 2017 03:00:58 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhVqT-0000Vs-12 for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 03:00:57 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E5A0D160831; Tue, 15 Aug 2017 00:00:50 -0700 (PDT) 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 uf3P_k-6avIc; Tue, 15 Aug 2017 00:00:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3B3D3160833; Tue, 15 Aug 2017 00:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 c_EsE-9IKelM; Tue, 15 Aug 2017 00:00:50 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 18CC5160831; Tue, 15 Aug 2017 00:00:50 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> <83efsdh81k.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Tue, 15 Aug 2017 00:00:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83efsdh81k.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii wrote: > we should not lose the feature that renaming a file on > macOS to a different letter-case works without nagging the user with > confirmations. I was hoping that the current code does that as-is on macOS. Someone need= s to=20 test that, though. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 08:45:39 2017 Received: (at submit) by debbugs.gnu.org; 15 Aug 2017 12:45:40 +0000 Received: from localhost ([127.0.0.1]:37806 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhbE3-0005fX-MV for submit@debbugs.gnu.org; Tue, 15 Aug 2017 08:45:39 -0400 Received: from eggs.gnu.org ([208.118.235.92]:32839) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhbE2-0005fP-7Z for submit@debbugs.gnu.org; Tue, 15 Aug 2017 08:45:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhbDw-0006rc-0f for submit@debbugs.gnu.org; Tue, 15 Aug 2017 08:45:32 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:52583) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dhbDv-0006rY-Tb for submit@debbugs.gnu.org; Tue, 15 Aug 2017 08:45:31 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhbDt-0006GV-Oj for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2017 08:45:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhbDr-0006ol-6o for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2017 08:45:29 -0400 Received: from [195.159.176.226] (port=41440 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dhbDq-0006nI-V9 for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2017 08:45:27 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dhbDd-00010o-KW for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2017 14:45:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation Date: Tue, 15 Aug 2017 13:45:02 +0100 Lines: 23 Message-ID: References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> <4dfc78db-b550-4cc6-efad-67b7c57c3cce@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@blaine.gmane.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (windows-nt) Cancel-Lock: sha1:hhrFtBSMEUBRAMTrgpIBYiOATik= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.8 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.8 (----) On Mon 14 Aug 2017, Paul Eggert wrote: > Paul Eggert wrote: >> I installed the patch on 'master' to help you do that. > > After rereading the Apple manual I installed the attached further patch into > master, so please try updating to the latest master before testing. This patch breaks the Windows build for mingw64: ../../src/fileio.c: In function 'Frename_file': ../../src/fileio.c:2300:41: error: duplicate case value case EEXIST: case EINVAL: case ENOSYS: case ENOTSUP: ^~~~ ../../src/fileio.c:2300:28: note: previously used here case EEXIST: case EINVAL: case ENOSYS: case ENOTSUP: ^~~~ A brief look suggests that the inclusion of ms-w32.h in conf_post.h is the culprit, as it defines some error numbers before errno.h is included, and thus overrides the conditional definitions in errno.h. AndyM From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 12:04:16 2017 Received: (at 27986) by debbugs.gnu.org; 15 Aug 2017 16:04:16 +0000 Received: from localhost ([127.0.0.1]:38384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dheKG-0007VT-3a for submit@debbugs.gnu.org; Tue, 15 Aug 2017 12:04:16 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dheKE-0007VN-R3 for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 12:04:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dheK5-0005qS-C0 for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 12:04:09 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dheK5-0005qM-97; Tue, 15 Aug 2017 12:04:05 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1888 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dheK4-00074R-PT; Tue, 15 Aug 2017 12:04:05 -0400 Date: Tue, 15 Aug 2017 19:04:01 +0300 Message-Id: <83d17whl72.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: (message from Paul Eggert on Mon, 14 Aug 2017 16:31:38 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <1002ee73-0ab5-409b-831f-0c283c322264@cs.ucla.edu> <83o9rignt6.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org > From: Paul Eggert > Date: Mon, 14 Aug 2017 16:31:38 -0700 > > Currently (rename-file A B) requires at least two system calls to work: one to test whether B is a directory, and the other to actually do the rename. This leads to race conditions if other actors change the file system between the two calls. > > For example, suppose a victim is about to execute (rename-file "/tmp/foo" "/tmp/bar" t), and suppose an attacker wants to destroy the victim's file /home/victim/secret/foo. The attacker can do (make-symbolic-link "/home/victim/secret" "/tmp/bar") You mean, the attacker creates this symlink between the time Emacs tests whether /tmp/bar is a directory and the time Emacs calls 'rename'? > and this will cause the victim to lose all the data in /home/victim/secret/bar even though the attacker is supposed to lack access to anything under /home/victim/secret. You mean, "lose data" because files in /tmp/foo will overwrite their namesakes in /home/victim/secret/bar? IOW, files in /home/victim/secret/bar which don't have identically-named counterparts in /tmp/foo will not be lost, right? (I'm not saying this is not a problem, I'm just trying to understand the meaning of "lose data" in this case.) If my understanding of the situation is correct, then such an attack will still be possible with the proposed change, if /tmp/bar exists, because Emacs will still issue two separate system calls, and the symlink can be created in-between, albeit at a price of deleting /tmp/bar first. Right? > As icing on the cake, the current behavior of (rename-file A B) disagrees with its documentation when B is an existing directory. Well, 2/3 of it. The 3rd instance, in the Emacs manual gets it right: [...] If the argument NEW is just a directory name, the real new name is in that directory, with the same non-directory component as OLD. For example, ‘M-x rename-file ~/foo /tmp ’ renames ‘~/foo’ to ‘/tmp/foo’. Note that there's no trailing slash in "/tmp". > There is no good solution to this problem. All solutions are bad, in that either they are not 100% backward compatible with existing behavior, or they continue to encourage insecure Elisp code. The proposed patch attempts to choose the least bad way forward, by making the default behavior more secure, at a relatively minor cost in compatibility. Most uses of rename-file etc. won't care about the change, and the ones that do care are likely to have security problems anyway. 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. If B doesn't end in a slash and rename_noreplace fails, and the value of errno from rename_noreplace doesn't indicate B is a directory, then test if it's a directory and fall back on the old behavior. We could then change our code that calls rename-file to make B end in a slash, thus encouraging secure code and leaving the insecure behavior only as backward-compatibility feature. This will make the insecure code limited to situation which are already insecure due to a separate call to rename_noreplace. > The proposed solution improves security, because a common pattern in Lisp code when creating a file BAR "atomically" is to create and write a temporary file FOO and then execute (rename-file FOO BAR). Currently, this approach can be attacked in the way described when BAR's parent directory is /tmp or any similar directory. With the proposed patch, this approach cannot be hijacked in this way, because BAR will be a file name and not a directory name. That is, the call to rename-file will specify whether the destination-directory semantics are desired, rather than relying on the state of the filesystem to specify it. This is more secure because the state of the filesystem is partially under control of attackers. 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? AFAIU, the 'rename' call will fail if B is a non-empty directory, but what if it's empty, and what does rename_noreplace do in these situations? Your documentation patches don't cover this use case; I think we should. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 12:08:41 2017 Received: (at 27986) by debbugs.gnu.org; 15 Aug 2017 16:08:41 +0000 Received: from localhost ([127.0.0.1]:38411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dheOX-0007Xh-9l for submit@debbugs.gnu.org; Tue, 15 Aug 2017 12:08:41 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37563) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dheOU-0007Xb-Qf for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 12:08:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dheOO-0000Tq-SD for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 12:08:33 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37578) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dheOO-0000Tm-Ov; Tue, 15 Aug 2017 12:08:32 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1892 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dheOO-0005B4-AJ; Tue, 15 Aug 2017 12:08:32 -0400 Date: Tue, 15 Aug 2017 19:08:29 +0300 Message-Id: <83a830hkzm.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: (message from Paul Eggert on Tue, 15 Aug 2017 00:00:49 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> <83efsdh81k.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 15 Aug 2017 00:00:49 -0700 > > Eli Zaretskii wrote: > > we should not lose the feature that renaming a file on > > macOS to a different letter-case works without nagging the user with > > confirmations. > > I was hoping that the current code does that as-is on macOS. In that case, I have no problems with the changes. From what Philipp wrote I concluded, perhaps wrongly, that this is not happening on macOS. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 12:19:10 2017 Received: (at 27986) by debbugs.gnu.org; 15 Aug 2017 16:19:10 +0000 Received: from localhost ([127.0.0.1]:38457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dheYg-0007cR-9t for submit@debbugs.gnu.org; Tue, 15 Aug 2017 12:19:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dheYe-0007cJ-Nv for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 12:19:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dheYU-0007FA-Ch for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 12:19:03 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dheYU-0007F3-9p; Tue, 15 Aug 2017 12:18:58 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1920 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dheYT-0006Bd-NI; Tue, 15 Aug 2017 12:18:58 -0400 Date: Tue, 15 Aug 2017 19:18:54 +0300 Message-Id: <837ey4hki9.fsf@gnu.org> From: Eli Zaretskii To: Andy Moreton In-reply-to: (message from Andy Moreton on Tue, 15 Aug 2017 13:45:02 +0100) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> <4dfc78db-b550-4cc6-efad-67b7c57c3cce@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Andy Moreton > Date: Tue, 15 Aug 2017 13:45:02 +0100 > > ../../src/fileio.c: In function 'Frename_file': > ../../src/fileio.c:2300:41: error: duplicate case value > case EEXIST: case EINVAL: case ENOSYS: case ENOTSUP: > ^~~~ > ../../src/fileio.c:2300:28: note: previously used here > case EEXIST: case EINVAL: case ENOSYS: case ENOTSUP: > ^~~~ Should be fixed now. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 13:24:14 2017 Received: (at 27986) by debbugs.gnu.org; 15 Aug 2017 17:24:15 +0000 Received: from localhost ([127.0.0.1]:38717 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhfZe-00088D-DI for submit@debbugs.gnu.org; Tue, 15 Aug 2017 13:24:14 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhfZb-000885-EW for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 13:24:12 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 863FA16086C; Tue, 15 Aug 2017 10:24:05 -0700 (PDT) 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 R94Ap7BK0m5e; Tue, 15 Aug 2017 10:24:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 09418160875; Tue, 15 Aug 2017 10:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 u1sAxXxeGc9g; Tue, 15 Aug 2017 10:24:03 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id CD6EB16086C; Tue, 15 Aug 2017 10:24:03 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii 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> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <8e6de468-600c-4f2d-a21a-c2ff3a63d065@cs.ucla.edu> Date: Tue, 15 Aug 2017 10:24:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83d17whl72.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------757B5890344FEF669DC582F9" Content-Language: en-US X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) This is a multi-part message in MIME format. --------------757B5890344FEF669DC582F9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >> and this will cause the victim to lose all the data in /home/victim/se= cret/bar even though the attacker is supposed to lack access to anything = under /home/victim/secret. >=20 > You mean, "lose data" because files in /tmp/foo will overwrite their > namesakes in /home/victim/secret/bar? Yes. It's not just losing data of course; the attacker can add files to t= he=20 victim directory. > If my understanding of the situation is correct, then such an attack > will still be possible with the proposed change, if /tmp/bar exists, > because Emacs will still issue two separate system calls, and the > symlink can be created in-between, albeit at a price of deleting > /tmp/bar first. Right? No, such an attack is not possible. Emacs will run rename_noreplace which= will=20 fail because /tmp/bar exists, then the attacker will remove /tmp/bar and = replace=20 it with a symlink, then Emacs will run rename ("/tmp/foo", "/tmp/bar") wh= ich=20 will fail because a directory like /tmp is sticky and the victim cannot r= emove=20 the attacker's symlink. The attack would fail in a different way if /tmp = were=20 not sticky: the victim would remove the attacker's symlink. >> As icing on the cake, the current behavior of (rename-file A B) disagr= ees with its documentation when B is an existing directory. >=20 > Well, 2/3 of it. The 3rd instance, in the Emacs manual gets it right: Unfortunately the manual does not get it right. The main part of that 3rd= =20 instance agrees with the proposed change, because it says the special cas= e=20 occurs if NEWNAME "is just a directory name" (on Unix, this means it ends= in=20 "/"). You are correct that the example is missing a "/", so I'll update t= he=20 proposed patch to fix that. That part of the documentation has some other confusion: a phrase "The sa= me rule=20 applies to all the remaining commands in this section" is clearly an edit= ing=20 error; it must be a revenant of when the section didn't talk about comman= ds like=20 insert-file. I just now installed the attached patch to fix that (this pa= tch=20 doesn't address the directory issue). The bigger picture here is that this part of Emacs behavior is so poorly=20 documented that it's unclear from the documentation what the intent was. > 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 attack= er can=20 create a nonempty directory B, then rename_noreplace will fail, then Emac= s will=20 determine that B is a directory, then the attacker can replace B with a s= ymlink=20 to the victim directory, and then Emacs will overwrite the victim. I imag= ine=20 other attacks are possible, this is just the first one off the top of my = head. > 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=20 succeed if B names an empty directory (this is all assuming B is not itse= lf a=20 directory name). Ideally MS-Windows would be compatible; if not, we'd hav= e to=20 document the incompatibility. AFAIU, the 'rename' call will fail if B is a non-empty > directory, but what if it's empty, and what does rename_noreplace do > in these situations? Your documentation patches don't cover this use > case; I think we should. Thanks, good point, I plan to update the proposed patch accordingly and t= o=20 follow up soon. --------------757B5890344FEF669DC582F9 Content-Type: text/x-patch; name="0001-New-manual-section-Copying-and-Naming.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-New-manual-section-Copying-and-Naming.patch" =46rom 5c3d0ce3e09bf070bb3c89caa9d88f25d4a39283 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 15 Aug 2017 10:06:44 -0700 Subject: [PATCH] New manual section "Copying and Naming" * doc/emacs/files.texi (Copying and Naming): New section, split off from Misc File Ops and containing the operations that copy, name or rename files. This fixes some confusion caused by the incorrect phrase "The same rule applies to all the remaining commands in this section" in the old manual. This change does not affect the confusion about directories (see Bug#27986 for ongoing discussion). --- doc/emacs/custom.texi | 2 +- doc/emacs/emacs.texi | 1 + doc/emacs/files.texi | 123 +++++++++++++++++++++++++++-----------------= ------ 3 files changed, 69 insertions(+), 57 deletions(-) diff --git a/doc/emacs/custom.texi b/doc/emacs/custom.texi index 1c9c14a..824fb6e 100644 --- a/doc/emacs/custom.texi +++ b/doc/emacs/custom.texi @@ -1710,7 +1710,7 @@ Init Rebinding specify the key sequence. Using a string is simpler, but only works for @acronym{ASCII} characters and Meta-modified @acronym{ASCII} characters. For example, here's how to bind @kbd{C-x M-l} to -@code{make-symbolic-link} (@pxref{Misc File Ops}): +@code{make-symbolic-link} (@pxref{Copying and Naming}): =20 @example (global-set-key "\C-x\M-l" 'make-symbolic-link) diff --git a/doc/emacs/emacs.texi b/doc/emacs/emacs.texi index a3eb422..f3e6c94 100644 --- a/doc/emacs/emacs.texi +++ b/doc/emacs/emacs.texi @@ -453,6 +453,7 @@ Top * Directories:: Creating, deleting, and listing file directories= =2E * Comparing Files:: Finding where two files differ. * Diff Mode:: Mode for editing file differences. +* Copying and Naming:: Copying, naming and renaming files. * Misc File Ops:: Other things you can do on files. * Compressed Files:: Accessing compressed files. * File Archives:: Operating on tar, zip, jar etc. archive files. diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi index 0b4e8ed..7bca988 100644 --- a/doc/emacs/files.texi +++ b/doc/emacs/files.texi @@ -33,6 +33,7 @@ Files * Directories:: Creating, deleting, and listing file directories= =2E * Comparing Files:: Finding where two files differ. * Diff Mode:: Mode for editing file differences. +* Copying and Naming:: Copying, naming and renaming files. * Misc File Ops:: Other things you can do on files. * Compressed Files:: Accessing compressed files. * File Archives:: Operating on tar, zip, jar etc. archive files. @@ -1545,6 +1546,72 @@ Diff Mode displayed in the echo area). With a prefix argument, it tries to modify the original source files rather than the patched source files. =20 +@node Copying and Naming +@section Copying, Naming and Renaming Files + + Emacs has several commands for copying, naming, and renaming files. +All of them read two file names @var{old} and @var{new} using the +minibuffer, and then copy or adjust a file's name accordingly; they do +not accept wildcard file names. + +In all these commands, if the argument @var{new} is just a directory +name, the real new name is in that directory, with the same +non-directory component as @var{old}. For example, @kbd{M-x +rename-file @key{RET} ~/foo @key{RET} +@c FIXME: This part of the example should be '/tmp/' not '/tmp', +@c because '/tmp' is not "just a directory name". +/tmp +@c +@key{RET}} renames @file{~/foo} to @file{/tmp/foo}. All these +commands ask for confirmation when the new file name already exists, +too. + +@findex copy-file +@cindex copying files + @kbd{M-x copy-file} copies the contents of the file @var{old} to the +file @var{new}. + +@findex copy-directory + @kbd{M-x copy-directory} copies directories, similar to the +@command{cp -r} shell command. If @var{new} is an existing directory, +it creates a copy of the @var{old} directory and puts it in @var{new}. +If @var{new} is not an existing directory, it copies all the contents +of @var{old} into a new directory named @var{new}. + +@cindex renaming files +@findex rename-file + @kbd{M-x rename-file} renames file @var{old} as @var{new}. If the +file name @var{new} already exists, you must confirm with @kbd{yes} or +renaming is not done; this is because renaming causes the old meaning +of the name @var{new} to be lost. If @var{old} and @var{new} are on +different file systems, the file @var{old} is copied and deleted. + +@ifnottex + If a file is under version control (@pxref{Version Control}), you +should rename it using @kbd{M-x vc-rename-file} instead of @kbd{M-x +rename-file}. @xref{VC Delete/Rename}. +@end ifnottex + +@findex add-name-to-file +@cindex hard links (creation) + @kbd{M-x add-name-to-file} adds an additional name to an existing +file without removing the old name. The new name is created as a hard +link to the existing file. The new name must belong on the same file +system that the file is on. On MS-Windows, this command works only if +the file resides in an NTFS file system. On MS-DOS, it works by +copying the file. + +@findex make-symbolic-link +@cindex symbolic links (creation) + @kbd{M-x make-symbolic-link} creates a symbolic link named +@var{new}, which points at @var{target}. The effect is that future +attempts to open file @var{new} will refer to whatever file is named +@var{target} at the time the opening is done, or will get an error if +the name @var{target} is nonexistent at that time. This command does +not expand the argument @var{target}, so that it allows you to specify +a relative name as the target of the link. On MS-Windows, this +command works only on MS Windows Vista and later. + @node Misc File Ops @section Miscellaneous File Operations =20 @@ -1581,62 +1648,6 @@ Misc File Ops delete-file}. @xref{VC Delete/Rename}. @end ifnottex =20 -@findex copy-file -@cindex copying files - @kbd{M-x copy-file} copies the contents of the file @var{old} to the -file @var{new}. - -@findex copy-directory - @kbd{M-x copy-directory} copies directories, similar to the -@command{cp -r} shell command. It prompts for a directory @var{old} -and a destination @var{new}. If @var{new} is an existing directory, -it creates a copy of the @var{old} directory and puts it in @var{new}. -If @var{new} is not an existing directory, it copies all the contents -of @var{old} into a new directory named @var{new}. - -@cindex renaming files -@findex rename-file - @kbd{M-x rename-file} reads two file names @var{old} and @var{new} -using the minibuffer, then renames file @var{old} as @var{new}. If -the file name @var{new} already exists, you must confirm with -@kbd{yes} or renaming is not done; this is because renaming causes the -old meaning of the name @var{new} to be lost. If @var{old} and -@var{new} are on different file systems, the file @var{old} is copied -and deleted. If the argument @var{new} is just a directory name, the -real new name is in that directory, with the same non-directory -component as @var{old}. For example, @kbd{M-x rename-file @key{RET} -~/foo @key{RET} /tmp @key{RET}} renames @file{~/foo} to -@file{/tmp/foo}. The same rule applies to all the remaining commands -in this section. All of them ask for confirmation when the new file -name already exists, too. - -@ifnottex - If a file is under version control (@pxref{Version Control}), you -should rename it using @kbd{M-x vc-rename-file} instead of @kbd{M-x -rename-file}. @xref{VC Delete/Rename}. -@end ifnottex - -@findex add-name-to-file -@cindex hard links (creation) - @kbd{M-x add-name-to-file} adds an additional name to an existing -file without removing its old name. The new name is created as a -hard link to the existing file. The new name must belong on the -same file system that the file is on. On MS-Windows, this command -works only if the file resides in an NTFS file system. On MS-DOS, it -works by copying the file. - -@findex make-symbolic-link -@cindex symbolic links (creation) - @kbd{M-x make-symbolic-link} reads two file names @var{target} and -@var{linkname}, then creates a symbolic link named @var{linkname}, -which points at @var{target}. The effect is that future attempts to -open file @var{linkname} will refer to whatever file is named -@var{target} at the time the opening is done, or will get an error if -the name @var{target} is nonexistent at that time. This command does -not expand the argument @var{target}, so that it allows you to specify -a relative name as the target of the link. On MS-Windows, this -command works only on MS Windows Vista and later. - @kindex C-x i @findex insert-file @kbd{M-x insert-file} (also @kbd{C-x i}) inserts a copy of the --=20 2.7.4 --------------757B5890344FEF669DC582F9-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 13:43:09 2017 Received: (at 27986) by debbugs.gnu.org; 15 Aug 2017 17:43:09 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Tue, 15 Aug 2017 20:42:46 +0300 Message-Id: <83zib0g221.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <8e6de468-600c-4f2d-a21a-c2ff3a63d065@cs.ucla.edu> (message from Paul Eggert on Tue, 15 Aug 2017 10:24:03 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 15:28:02 2017 Received: (at 27986) by debbugs.gnu.org; 15 Aug 2017 19:28:02 +0000 Received: from localhost ([127.0.0.1]:39275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhhVS-0002eU-Fm for submit@debbugs.gnu.org; Tue, 15 Aug 2017 15:28:02 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhhVQ-0002e7-3q for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 15:28:00 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 15D85160875; Tue, 15 Aug 2017 12:27:54 -0700 (PDT) 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 TIcXz_WA-kuS; Tue, 15 Aug 2017 12:27:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4571E160881; Tue, 15 Aug 2017 12:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 kzN65nG3_Qtt; Tue, 15 Aug 2017 12:27:53 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 21101160875; Tue, 15 Aug 2017 12:27:53 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii 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> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <2bb4b7ee-6bf9-df3d-5cd8-ae7992b9f2e7@cs.ucla.edu> Date: Tue, 15 Aug 2017 12:27:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83zib0g221.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii wrote: > How would they know to create B before Emacs issues any system call > that uses B? Because the attackers know how Emacs work and are attempting to exploit i= ts=20 security hole. > 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)? The case in question trashes a directory that the attacker lacks permissi= on to.=20 The case you're talking about does not: it merely causes rename-file to f= ail. > we should be backward compatible as a fallback. I don't see how this can work, if the fallback method relies on two syste= m calls=20 that can fall victim to a race. I tried pretty hard to come up with secur= e and=20 backward-compatible approaches before proposing the change. I could not c= ome up=20 with any, and doubt whether anyone else could either. Another possibility is to implement new functions (say: file-copy, file-r= ename,=20 file-link, file-symlink, and directory-copy) that behave like the existin= g=20 functions except without the security hole, modify callers to use these n= ew=20 functions, and then mark the existing functions as deprecated due to secu= rity=20 concerns. I suspect that this would be more disruptive overall than the p= roposed=20 change, though (albeit disruptive in a different way). From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 15 22:37:06 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 02:37:06 +0000 Received: from localhost ([127.0.0.1]:40069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhoCg-0002pf-7U for submit@debbugs.gnu.org; Tue, 15 Aug 2017 22:37:06 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhoCf-0002pB-7K for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 22:37:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dhoCW-0000Vf-QE for 27986@debbugs.gnu.org; Tue, 15 Aug 2017 22:36:59 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dhoCW-0000VZ-Fl; Tue, 15 Aug 2017 22:36:56 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2409 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dhoCV-0002LP-TT; Tue, 15 Aug 2017 22:36:56 -0400 Date: Wed, 16 Aug 2017 05:36:43 +0300 Message-Id: <83wp64fdc4.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <2bb4b7ee-6bf9-df3d-5cd8-ae7992b9f2e7@cs.ucla.edu> (message from Paul Eggert on Tue, 15 Aug 2017 12:27:52 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org > From: Paul Eggert > Date: Tue, 15 Aug 2017 12:27:52 -0700 > > Eli Zaretskii wrote: > > > How would they know to create B before Emacs issues any system call > > that uses B? > > Because the attackers know how Emacs work and are attempting to exploit its > security hole. Knowing how Emacs works is not enough: they need to actually know the name of the directory to create, and I don't see how they can do that without seeing some system call which names that directory. > > 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)? > > The case in question trashes a directory that the attacker lacks permission to. > The case you're talking about does not: it merely causes rename-file to fail. No, it's the same use case. In both of them the attacker creates a directory ahead of Emacs using it in some system call. > Another possibility is to implement new functions (say: file-copy, file-rename, > file-link, file-symlink, and directory-copy) that behave like the existing > functions except without the security hole, modify callers to use these new > functions, and then mark the existing functions as deprecated due to security > concerns. 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. If we decide to use the old variants, deprecation might not be the right mechanism for promoting the new variants. > I suspect that this would be more disruptive overall than the proposed > change, though (albeit disruptive in a different way). How so? From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 01:06:49 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 05:06:49 +0000 Received: from localhost ([127.0.0.1]:40127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhqXZ-00067i-Co for submit@debbugs.gnu.org; Wed, 16 Aug 2017 01:06:49 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhqXX-00067V-Bv for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 01:06:48 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 99EC6160869; Tue, 15 Aug 2017 22:06:39 -0700 (PDT) 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 vHaDN3bP924r; Tue, 15 Aug 2017 22:06:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A5FA816086A; Tue, 15 Aug 2017 22:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 prAQ1nS0k-H5; Tue, 15 Aug 2017 22:06:38 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 80787160869; Tue, 15 Aug 2017 22:06:38 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii 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> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Tue, 15 Aug 2017 22:06:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83wp64fdc4.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii wrote: > 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 pro= gram=20 that it is running. We cannot rely on security-via-obscurity; we must ass= ume=20 that the attackers know not only the Emacs C source code, but the Lisp co= de that=20 Emacs runs. Such an attacker will know the name of the directory to creat= e. >>> 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)? >> >> The case in question trashes a directory that the attacker lacks permi= ssion to. >> The case you're talking about does not: it merely causes rename-file t= o fail. >=20 > No, it's the same use case. In both of them the attacker creates a > directory ahead of Emacs using it in some system call. Sure, but in the use case I'm talking about, the attacker can trash the v= ictim's=20 directory even though it's write-protected. In the case you're talking ab= out,=20 the attacker can't do anything other than what the attacker could do alre= ady. >> Another possibility is to implement new functions (say: file-copy, fil= e-rename, >> file-link, file-symlink, and directory-copy) that behave like the exis= ting >> functions except without the security hole, modify callers to use thes= e new >> functions, and then mark the existing functions as deprecated due to s= ecurity >> concerns. >=20 > 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=20 function; if they call M-x file-copy they'll get the new one. Admittedly = there=20 will be confusion (see below). >> I suspect that this would be more disruptive overall than the proposed >> change, though (albeit disruptive in a different way). >=20 > How so? It'll be disruption caused by the extra complexity: pairs of functions th= at do=20 nearly the same thing, with user confusion over which function to call, a= nd=20 people calling the wrong one. Tramp will need at least four new methods t= o=20 support, probably more. The complexity and confusion will go on and on, a= nd will=20 cost more than will be saved by the backward compatibility. It would be w= orth=20 all this trouble if people needed the old behavior, but they mostly do no= t. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 10:21:59 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 14:21:59 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Wed, 16 Aug 2017 17:21:33 +0300 Message-Id: <83valnfv9u.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: (message from Paul Eggert on Tue, 15 Aug 2017 22:06:38 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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.) From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 11:15:49 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 15:15:49 +0000 Received: from localhost ([127.0.0.1]:41337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di02t-0003Y0-M8 for submit@debbugs.gnu.org; Wed, 16 Aug 2017 11:15:49 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di02r-0003Xl-5q for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 11:15:45 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6237F160871; Wed, 16 Aug 2017 08:15:39 -0700 (PDT) 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 Lz1wychl2WUw; Wed, 16 Aug 2017 08:15:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8F976160887; Wed, 16 Aug 2017 08:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 ChZW86kxmp5J; Wed, 16 Aug 2017 08:15:38 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 66FBE160871; Wed, 16 Aug 2017 08:15:38 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii 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> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <7f0c12f6-57eb-63b9-c296-e062cbf0710c@cs.ucla.edu> Date: Wed, 16 Aug 2017 08:15:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83valnfv9u.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii wrote: > You are describing a situation where the attacker somehow knows what > file/directory will be accessed_ahead_ of Emacs actually accessing > it. Sure, and this happens all the time. Emacs prepares a copy of a file with= the=20 intent to rename the copy to the original atomically. The attacker will k= now=20 that this is what Emacs will do, by looking at the file system or the sys= calls=20 Emacs issues before its code calls rename-file (e.g., Emacs will read the= old=20 file). So I am not supposing any kind of superhuman attack. I do take your point that interactive use is different. So, here is a pro= posed=20 change to the patch: if the ok-is-already-exists flag is an integer (whic= h=20 suggests interactive use), and if the destination is not a directory name= =20 (trailing "/") but happens to be an existing directory, then Emacs asks t= he user=20 if it is OK to rename to a subfile of the destination. This would allay m= ost the=20 security concerns that I have, and I hope it would address most of the=20 backward-compatibility concerns that you have. > I thought you were proposing to redirect the interactive commands to > the new functions. I was not proposing to redirect 'M-x rename-file' etc. They would continu= e to=20 use the old insecure behavior, for compatibility reasons. > we cannot obsolete user commands. Not immediately, no. But we can mark them as obsolescent and warn users a= bout=20 their use, and remove them eventually. This issue of obsolescence is moot, though, if you agree with the above=20 suggestion about ok-if-already-exists. > if people want secure code, > they _will_ use the more secure variants Emacs is a relatively large and complex system, and we cannot expect user= s to be=20 familiar with every detail. Emacs should have safe defaults, not unsafe o= nes. The situation with "mv" was different, as POSIX and longstanding document= ation=20 required the unsafe behavior and many scripts relied on it. In contrast, = the=20 Emacs documentation is thoroughly muddled and contradictory in this area,= and=20 code using rename-file etc. would more likely benefit from the proposed c= hange=20 (because of improved security) than be hurt by it (by loss of backward=20 compatibility with poorly-documented and insecure behavior). From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 12:06:43 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 16:06:43 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Wed, 16 Aug 2017 19:06:02 +0300 Message-Id: <83o9rffqfp.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert , Richard Stallman In-reply-to: <7f0c12f6-57eb-63b9-c296-e062cbf0710c@cs.ucla.edu> (message from Paul Eggert on Wed, 16 Aug 2017 08:15:34 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 13:19:45 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 17:19:45 +0000 Received: from localhost ([127.0.0.1]:41435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di1yq-0001di-Te for submit@debbugs.gnu.org; Wed, 16 Aug 2017 13:19:45 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:34618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di1yp-0001dS-Cu for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 13:19:43 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3489F160886; Wed, 16 Aug 2017 10:19:37 -0700 (PDT) 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 zhk-cZFv9l_N; Wed, 16 Aug 2017 10:19:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2E79616088C; Wed, 16 Aug 2017 10:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 jD_xeZMbp6jq; Wed, 16 Aug 2017 10:19:36 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 0727D160886; Wed, 16 Aug 2017 10:19:36 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii , Richard Stallman 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> <83o9rffqfp.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Wed, 16 Aug 2017 10:19:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83o9rffqfp.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii wrote: > Did you look at all the users of these functions in > our codebase? I have not looked at every single one in detail. I've looked at a fair sa= mple.=20 See below for more discussion. > E.g., I see at least one use of rename-file in Gnus > that moves a directory, possibly 2 such uses. Moving a directory is not a problem. The only problem is when the destina= tion is=20 a directory but not a directory name and the intent is to change an entry= in=20 that directory rather than to change the original destination. I agree that some uses in code will need to be adjusted. Most won't, thou= gh. For=20 example, in the first occurrence of the string "rename-file" in Gnus, whe= re=20 gnus-agent-rename-group calls (gnus-rename-file old-path new-path t), the= intent=20 is to rename OLD-PATH to NEW-PATH, not to rename it to be an subsidiary e= ntry to=20 NEW-PATH. For this particular example, the proposed change is slightly=20 beneficial, since it prevents rename-file from doing the wrong thing in t= he=20 (admittedly unlikely) event that some other process changes NEW-PATH to a= =20 directory while Gnus is operating. > 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. This should be quite rare. The only scenario I see matching your concern = is if=20 the source is a directory, the destination is not a directory name but is= an=20 empty directory and is not a symlink, and the destination is not a descen= dant of=20 the source. Although not impossible, this will happen so rarely that it d= oesn't=20 invalidate the proposed change. > At the very least, all the users in Emacs > should be audited and fixed as needed. Sure, I'll volunteer to do that. There are only 172 lines containing the = string=20 "rename-file" in our Emacs Lisp code base, for example, and it shouldn't = be that=20 much work to check them. I've looked at this issue fairly carefully, and I'm afraid the solution I= 've=20 proposed is the best way forward if we want to close the security hole in= Emacs. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 13:31:21 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 17:31:21 +0000 Received: from localhost ([127.0.0.1]:41446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di2A5-0001va-7W for submit@debbugs.gnu.org; Wed, 16 Aug 2017 13:31:21 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33437) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di2A3-0001vM-Pt for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 13:31:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1di29x-0007jc-PB for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 13:31:14 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59814) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1di29q-0007bU-IH; Wed, 16 Aug 2017 13:31:06 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2884 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1di29j-0001IL-Dv; Wed, 16 Aug 2017 13:30:59 -0400 Date: Wed, 16 Aug 2017 20:30:44 +0300 Message-Id: <83efsbfmij.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert , John Wiegley , Stefan Monnier In-reply-to: (message from Paul Eggert on Wed, 16 Aug 2017 10:19:35 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation 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> <83o9rffqfp.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org, rms@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org > From: Paul Eggert > Date: Wed, 16 Aug 2017 10:19:35 -0700 > > > 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. > > This should be quite rare. The only scenario I see matching your concern is if > the source is a directory, the destination is not a directory name but is an > empty directory and is not a symlink, and the destination is not a descendant of > the source. Although not impossible, this will happen so rarely that it doesn't > invalidate the proposed change. I don't think we know how rare that is. And if it is very rare, I'm not sure it's better, because it means such problems might go unnoticed and/or unfixed for years. > I've looked at this issue fairly carefully, and I'm afraid the solution I've > proposed is the best way forward if we want to close the security hole in Emacs. Let's hear more opinions, okay? From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 14:07:04 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 18:07:04 +0000 Received: from localhost ([127.0.0.1]:41467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di2ie-0002ki-K3 for submit@debbugs.gnu.org; Wed, 16 Aug 2017 14:07:04 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40425) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di2ic-0002kF-JK for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 14:07:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1di2iR-0008C2-LQ for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 14:06:57 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1di2iG-0007to-83; Wed, 16 Aug 2017 14:06:40 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1di2iD-0002lN-DE; Wed, 16 Aug 2017 14:06:37 -0400 From: Glenn Morris To: Eli Zaretskii Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> X-Spook: advisors assassination interception Conventional weapon X-Ran: kH(Q6RL"7oiu.tj`eH!.HVsdJ|r.0$JxeW>jsB]5/=e<|:O^MIGBRHD>+ly,3:+[)/x)PB X-Hue: yellow X-Debbugs-No-Ack: yes X-Attribution: GM Date: Wed, 16 Aug 2017 14:06:37 -0400 In-Reply-To: <83efsbfmij.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 16 Aug 2017 20:30:44 +0300") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: Paul Eggert , rms@gnu.org, John Wiegley , p.stephani2@gmail.com, Stefan Monnier , 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Eli Zaretskii wrote: > Let's hear more opinions, okay? FWIW, I think Paul's proposal is eminently sensible. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 15:33:42 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 19:33:42 +0000 Received: from localhost ([127.0.0.1]:41521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di44T-00011C-SM for submit@debbugs.gnu.org; Wed, 16 Aug 2017 15:33:42 -0400 Received: from limerock02.mail.cornell.edu ([128.84.13.242]:43589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di44T-000110-07 for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 15:33:41 -0400 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock02.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id v7GJXXxN005595; Wed, 16 Aug 2017 15:33:33 -0400 Received: from [192.168.0.4] (mta-68-175-129-7.twcny.rr.com [68.175.129.7] (may be forged)) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id v7GJXU2i008787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Aug 2017 15:33:32 -0400 Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Paul Eggert , Philipp Stephani , Eli Zaretskii References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> From: Ken Brown Message-ID: <6dbd21fd-d191-812a-5810-cb4fbcfbcb20@cornell.edu> Date: Wed, 16 Aug 2017 15:33:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PMX-Cornell-Gauge: Gauge=XXXXX X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On 8/14/2017 7:03 PM, Paul Eggert wrote > Now that renameat_noreplace works on DOS_NT, would it make sense to > apply the attached further patch as well? If we can get > renameat_noreplace to work on Cygwin the we could simplify the fileio.c > code even further. I'm in the process of writing an implementation of something like 'renameat2', which I'll submit to the Cygwin developers. Even if it's accepted, however, I think we'll still need to retain the case-insensitivity test for users of old versions of Cygwin, unless there's a decision to remove that because of the security concerns currently being discussed. Ken From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 18:31:34 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 22:31:35 +0000 Received: from localhost ([127.0.0.1]:41654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di6qc-0007JK-Of for submit@debbugs.gnu.org; Wed, 16 Aug 2017 18:31:34 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:51851) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di6qZ-0007JB-TQ for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 18:31:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v7GMVEgT019303; Wed, 16 Aug 2017 18:31:16 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 46BDE66334; Wed, 16 Aug 2017 18:31:14 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation Message-ID: 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> Date: Wed, 16 Aug 2017 18:31:14 -0400 In-Reply-To: <83efsbfmij.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 16 Aug 2017 20:30:44 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6095=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6095> : inlines <6024> : streams <1758894> : uri <2484405> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org, p.stephani2@gmail.com, Paul Eggert , rms@gnu.org, John Wiegley X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) >> This should be quite rare. The only scenario I see matching your >> concern is if the source is a directory, the destination is not >> a directory name but is an empty directory and is not a symlink, and >> the destination is not a descendant of the source. Although not >> impossible, this will happen so rarely that it doesn't invalidate >> the proposed change. Paul's suggestion makes a lot of sense to me, but I don't quite understand the above: why does the emptiness of the destination directory matter? Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 19:56:59 2017 Received: (at 27986) by debbugs.gnu.org; 16 Aug 2017 23:56:59 +0000 Received: from localhost ([127.0.0.1]:41702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di8BH-0004Yt-69 for submit@debbugs.gnu.org; Wed, 16 Aug 2017 19:56:59 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:54690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di8BE-0004Yg-PQ for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 19:56:57 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E79ED160862; Wed, 16 Aug 2017 16:56:49 -0700 (PDT) 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 0ba-YInQyeyR; Wed, 16 Aug 2017 16:56:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 34379160865; Wed, 16 Aug 2017 16:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 QFdW5h33To6B; Wed, 16 Aug 2017 16:56:49 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 15DC2160862; Wed, 16 Aug 2017 16:56:49 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Stefan Monnier , Eli Zaretskii 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Wed, 16 Aug 2017 16:56:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org, p.stephani2@gmail.com, John Wiegley , rms@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 08/16/2017 03:31 PM, Stefan Monnier wrote: >>> This should be quite rare. The only scenario I see matching your >>> concern is if the source is a directory, the destination is not >>> a directory name but is an empty directory and is not a symlink, and >>> the destination is not a descendant of the source. Although not >>> impossible, this will happen so rarely that it doesn't invalidate >>> the proposed change. > Paul's suggestion makes a lot of sense to me, but I don't quite > understand the above: why does the emptiness of the destination > directory matter? It's because the system call rename(A,B) always fails when B is a nonempty directory. Hence the proposed (rename-file A B) will fail if B is not a directory name but happens to name a nonempty directory, and therefore rename-file noisily fails instead of silently behaving differently in this case (which was Eli's concern). Conversely, if B is an empty directory then rename(A,B) can succeed (and thereby remove the old B) if all the other conditions are met. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 20:04:34 2017 Received: (at 27986) by debbugs.gnu.org; 17 Aug 2017 00:04:34 +0000 Received: from localhost ([127.0.0.1]:41715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di8Ic-0004lD-Ck for submit@debbugs.gnu.org; Wed, 16 Aug 2017 20:04:34 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:53787) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di8IZ-0004l5-Q0 for 27986@debbugs.gnu.org; Wed, 16 Aug 2017 20:04:32 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v7H04Qtb022181; Wed, 16 Aug 2017 20:04:27 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 0397D66334; Wed, 16 Aug 2017 20:04:25 -0400 (EDT) From: Stefan Monnier To: Paul Eggert Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation Message-ID: 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> Date: Wed, 16 Aug 2017 20:04:25 -0400 In-Reply-To: (Paul Eggert's message of "Wed, 16 Aug 2017 16:56:48 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6095=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6095> : inlines <6024> : streams <1758904> : uri <2484448> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 27986 Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org, Eli Zaretskii , John Wiegley , rms@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > case (which was Eli's concern). Conversely, if B is an empty directory then > rename(A,B) can succeed (and thereby remove the old B) if all the other > conditions are met. Ah, right, if it's an empty dir then it can be removed/replaced atomically. Thanks. It does seem like the odd case should be rare, then, indeed. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 19 02:54:44 2017 Received: (at 27986) by debbugs.gnu.org; 19 Aug 2017 06:54:44 +0000 Received: from localhost ([127.0.0.1]:44943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dixee-0007Fy-9Q for submit@debbugs.gnu.org; Sat, 19 Aug 2017 02:54:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33441) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dixed-0007Fk-1W for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 02:54:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dixeX-0005GS-1d for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 02:54:37 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dixeP-00059l-K0; Sat, 19 Aug 2017 02:54:29 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1644 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dixeI-0007Xd-Aw; Sat, 19 Aug 2017 02:54:22 -0400 Date: Sat, 19 Aug 2017 09:54:12 +0300 Message-Id: <83efs8dp4b.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Wed, 16 Aug 2017 18:31:14 -0400) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org, p.stephani2@gmail.com, eggert@cs.ucla.edu, rms@gnu.org, johnw@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Stefan Monnier > Cc: Paul Eggert , John Wiegley , > rms@gnu.org, p.stephani2@gmail.com, 27986@debbugs.gnu.org > Date: Wed, 16 Aug 2017 18:31:14 -0400 > > Paul's suggestion makes a lot of sense to me John, what's your take on this? From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 19 17:30:19 2017 Received: (at 27986) by debbugs.gnu.org; 19 Aug 2017 21:30:19 +0000 Received: from localhost ([127.0.0.1]:45889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djBJz-0004Dh-GR for submit@debbugs.gnu.org; Sat, 19 Aug 2017 17:30:19 -0400 Received: from limerock01.mail.cornell.edu ([128.84.13.241]:44503) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djBJx-0004DV-D1 for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 17:30:17 -0400 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id v7JLU2CJ018201; Sat, 19 Aug 2017 17:30:02 -0400 Received: from [192.168.0.4] (mta-68-175-129-7.twcny.rr.com [68.175.129.7] (may be forged)) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id v7JLU02g026494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 19 Aug 2017 17:30:01 -0400 Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation From: Ken Brown To: Paul Eggert , Philipp Stephani , Eli Zaretskii References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> <6dbd21fd-d191-812a-5810-cb4fbcfbcb20@cornell.edu> Message-ID: <0720ef94-7787-94e7-a44d-576ec7f75607@cornell.edu> Date: Sat, 19 Aug 2017 17:30:01 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6dbd21fd-d191-812a-5810-cb4fbcfbcb20@cornell.edu> Content-Type: multipart/mixed; boundary="------------DD03CF9B65BD18C2DFFC173A" Content-Language: en-US X-PMX-Cornell-Gauge: Gauge=XXXXX X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a multi-part message in MIME format. --------------DD03CF9B65BD18C2DFFC173A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/16/2017 3:33 PM, Ken Brown wrote: > On 8/14/2017 7:03 PM, Paul Eggert wrote >> Now that renameat_noreplace works on DOS_NT, would it make sense to >> apply the attached further patch as well? If we can get >> renameat_noreplace to work on Cygwin the we could simplify the >> fileio.c code even further. > > I'm in the process of writing an implementation of something like > 'renameat2', which I'll submit to the Cygwin developers. This is now done. The implementation will appear in the next Cygwin release. When that release occurs, I'll install something like the attached patch. Question: Is the patch OK as is, or should I make the call to renameat2 conditional on CYGWIN? In other words, is it safe to assume that renameat2 is defined on any platform on which RENAME_NOREPLACE is defined but not SYS_renameat2? Ken --------------DD03CF9B65BD18C2DFFC173A Content-Type: text/plain; charset=UTF-8; name="0001-Implement-renameat_noreplace-on-recent-Cygwin.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-Implement-renameat_noreplace-on-recent-Cygwin.patch" RnJvbSBiOWVmNGNhOTk1MzUwZDFhNTIwYWJhNjZkZTFkNWU0MjA5ZjNlYjkxIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZW4gQnJvd24gPGticm93bkBjb3JuZWxsLmVkdT4K RGF0ZTogU2F0LCAxOSBBdWcgMjAxNyAxNzoxNzoyNyAtMDQwMApTdWJqZWN0OiBbUEFUQ0hd IEltcGxlbWVudCByZW5hbWVhdF9ub3JlcGxhY2Ugb24gcmVjZW50IEN5Z3dpbgoKKiBzcmMv c3lzZGVwLmMgW0NZR1dJTl06IEluY2x1ZGUgY3lnd2luL2ZzLmguCihyZW5hbWVhdF9ub3Jl cGxhY2UpIFtSRU5BTUVfTk9SRVBMQUNFXTogVXNlIHJlbmFtZWF0Mi4KKEJ1ZyMyNzk4NikK LS0tCiBzcmMvc3lzZGVwLmMgfCA2ICsrKysrKwogMSBmaWxlIGNoYW5nZWQsIDYgaW5zZXJ0 aW9ucygrKQoKZGlmZiAtLWdpdCBhL3NyYy9zeXNkZXAuYyBiL3NyYy9zeXNkZXAuYwppbmRl eCAxMmU5YzgzZWU5Li43NzIyMTA5N2RiIDEwMDY0NAotLS0gYS9zcmMvc3lzZGVwLmMKKysr IGIvc3JjL3N5c2RlcC5jCkBAIC00Miw2ICs0MiwxMCBAQCBhbG9uZyB3aXRoIEdOVSBFbWFj cy4gIElmIG5vdCwgc2VlIDxodHRwOi8vd3d3LmdudS5vcmcvbGljZW5zZXMvPi4gICovCiAj IGluY2x1ZGUgPHN5cy9zeXNjYWxsLmg+CiAjZW5kaWYKIAorI2lmZGVmIENZR1dJTgorIyBp bmNsdWRlIDxjeWd3aW4vZnMuaD4KKyNlbmRpZgorCiAjaWYgZGVmaW5lZCBEQVJXSU5fT1Mg fHwgZGVmaW5lZCBfX0ZyZWVCU0RfXwogIyBpbmNsdWRlIDxzeXMvc3lzY3RsLmg+CiAjZW5k aWYKQEAgLTI2ODUsNiArMjY4OSw4IEBAIHJlbmFtZWF0X25vcmVwbGFjZSAoaW50IHNyY2Zk LCBjaGFyIGNvbnN0ICpzcmMsIGludCBkc3RmZCwgY2hhciBjb25zdCAqZHN0KQogewogI2lm IGRlZmluZWQgU1lTX3JlbmFtZWF0MiAmJiBkZWZpbmVkIFJFTkFNRV9OT1JFUExBQ0UKICAg cmV0dXJuIHN5c2NhbGwgKFNZU19yZW5hbWVhdDIsIHNyY2ZkLCBzcmMsIGRzdGZkLCBkc3Qs IFJFTkFNRV9OT1JFUExBQ0UpOworI2VsaWYgZGVmaW5lZCBSRU5BTUVfTk9SRVBMQUNFCS8q IEN5Z3dpbiA+PSAyLjkuMC4gKi8KKyAgcmV0dXJuIHJlbmFtZWF0MiAoc3JjZmQsIHNyYywg ZHN0ZmQsIGRzdCwgUkVOQU1FX05PUkVQTEFDRSk7CiAjZWxpZiBkZWZpbmVkIFJFTkFNRV9F WENMCiAgIHJldHVybiByZW5hbWVhdHhfbnAgKHNyY2ZkLCBzcmMsIGRzdGZkLCBkc3QsIFJF TkFNRV9FWENMKTsKICNlbHNlCi0tIAoyLjE0LjEKCg== --------------DD03CF9B65BD18C2DFFC173A-- From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 19 17:34:09 2017 Received: (at 27986) by debbugs.gnu.org; 19 Aug 2017 21:34:09 +0000 Received: from localhost ([127.0.0.1]:45893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djBNh-0004LI-40 for submit@debbugs.gnu.org; Sat, 19 Aug 2017 17:34:09 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djBNf-0004L6-4z for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 17:34:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djBNZ-0006tg-6Y for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 17:34:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35716) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djBNZ-0006tE-2U for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 17:34:01 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1djBNU-0000rW-80; Sat, 19 Aug 2017 17:33:56 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: 27986@debbugs.gnu.org Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without Message-Id: Date: Sat, 19 Aug 2017 17:33:56 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] I haven't followed the discussion, but I'm told there is a proposal to make this change: > Btw, in case it isn't clear: the issue at hand is an incompatible > change to rename-file (and probably also other functions, like > copy-file). Where previously (rename-file A B) with B a directory > will move A into B/A, under the proposed change it will only do so if > B actually ended in a slash; otherwise it will move A to B, deleting B > if it exists. The incompatibility will manifest itself if some old > code expects to get B/A, but instead gets either an error (if B is a > non-empty directory) or B silently removed (if it is empty). Assuming this applies only when directory B is empty, so that this won't delete non-empty directories, then I don't have any objection. I would object to deleting non-empty directories here. Another option that might be good is to make this operation always signal an error in the case where B is a directory and does not end with a slash. I don't have an opinion about which of those two is better. -- Dr Richard Stallman President, Free Software Foundation (gnu.org, fsf.org) Internet Hall-of-Famer (internethalloffame.org) Skype: No way! See stallman.org/skype.html. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 19 17:37:21 2017 Received: (at 27986) by debbugs.gnu.org; 19 Aug 2017 21:37:21 +0000 Received: from localhost ([127.0.0.1]:45897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djBQn-0004Pj-K5 for submit@debbugs.gnu.org; Sat, 19 Aug 2017 17:37:21 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djBQm-0004PW-4h for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 17:37:20 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 75FA5160883; Sat, 19 Aug 2017 14:37:14 -0700 (PDT) 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 HiBK-QBSp-wr; Sat, 19 Aug 2017 14:37:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B884116088B; Sat, 19 Aug 2017 14:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 2fE6aHZ3xuCJ; Sat, 19 Aug 2017 14:37:13 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 8E1D5160883; Sat, 19 Aug 2017 14:37:13 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Ken Brown , Philipp Stephani , Eli Zaretskii References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> <6dbd21fd-d191-812a-5810-cb4fbcfbcb20@cornell.edu> <0720ef94-7787-94e7-a44d-576ec7f75607@cornell.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Sat, 19 Aug 2017 14:37:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0720ef94-7787-94e7-a44d-576ec7f75607@cornell.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Ken Brown wrote: > This is now done. The implementation will appear in the next Cygwin release. > When that release occurs, I'll install something like the attached patch. Thanks. > Question: Is the patch OK as is, or should I make the call to renameat2 > conditional on CYGWIN? In other words, is it safe to assume that renameat2 is > defined on any platform on which RENAME_NOREPLACE is defined but not SYS_renameat2? It should be OK, for the same reason the RENAME_EXCL branch is OK (it assumes renameatx_np). If we run across some future platform where it doesn't work, we can port it then. As far as I know, Cygwin will be the first platform with renameat2 in its C library. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 19 18:05:07 2017 Received: (at 27986) by debbugs.gnu.org; 19 Aug 2017 22:05:08 +0000 Received: from localhost ([127.0.0.1]:45908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djBrf-00055q-Nl for submit@debbugs.gnu.org; Sat, 19 Aug 2017 18:05:07 -0400 Received: from limerock04.mail.cornell.edu ([128.84.13.244]:41872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djBrc-00055I-JD for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 18:05:04 -0400 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock04.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id v7JM4ohP019013; Sat, 19 Aug 2017 18:04:50 -0400 Received: from [192.168.0.4] (mta-68-175-129-7.twcny.rr.com [68.175.129.7] (may be forged)) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id v7JM4mb6020466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 19 Aug 2017 18:04:49 -0400 Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Paul Eggert , Philipp Stephani , Eli Zaretskii References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> <6dbd21fd-d191-812a-5810-cb4fbcfbcb20@cornell.edu> <0720ef94-7787-94e7-a44d-576ec7f75607@cornell.edu> From: Ken Brown Message-ID: <5b8f4814-a6bd-d373-f0e6-217845b44f1d@cornell.edu> Date: Sat, 19 Aug 2017 18:04:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-PMX-Cornell-Gauge: Gauge=XXXXX X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On 8/19/2017 5:37 PM, Paul Eggert wrote: > Ken Brown wrote: >> This is now done.  The implementation will appear in the next Cygwin >> release. When that release occurs, I'll install something like the >> attached patch. > > Thanks. > >> Question: Is the patch OK as is, or should I make the call to >> renameat2 conditional on CYGWIN?  In other words, is it safe to assume >> that renameat2 is defined on any platform on which RENAME_NOREPLACE is >> defined but not SYS_renameat2? > > It should be OK, for the same reason the RENAME_EXCL branch is OK (it > assumes renameatx_np). If we run across some future platform where it > doesn't work, we can port it then. As far as I know, Cygwin will be the > first platform with renameat2 in its C library. Is there any (good) reason that glibc doesn't provide a wrapper for it? It seems that this would be pretty trivial to do. Ken From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 19 18:38:58 2017 Received: (at 27986) by debbugs.gnu.org; 19 Aug 2017 22:38:59 +0000 Received: from localhost ([127.0.0.1]:45919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djCOQ-0005rG-NN for submit@debbugs.gnu.org; Sat, 19 Aug 2017 18:38:58 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djCOP-0005r4-M6 for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 18:38:57 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3A9AB160885; Sat, 19 Aug 2017 15:38:51 -0700 (PDT) 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 oGj0qLrWCLGx; Sat, 19 Aug 2017 15:38:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 848C316088E; Sat, 19 Aug 2017 15:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 j-26AOc4ep2Y; Sat, 19 Aug 2017 15:38:50 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 659B4160885; Sat, 19 Aug 2017 15:38:50 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Ken Brown , Philipp Stephani , Eli Zaretskii References: <61980dde-3d68-7200-e7f4-98f62e410060@cs.ucla.edu> <0e80a1cf-8217-9e9a-a00f-9fdbd6575fc4@cs.ucla.edu> <0a79089f-36ed-8183-a3bf-6cfa32cb9028@cs.ucla.edu> <6dbd21fd-d191-812a-5810-cb4fbcfbcb20@cornell.edu> <0720ef94-7787-94e7-a44d-576ec7f75607@cornell.edu> <5b8f4814-a6bd-d373-f0e6-217845b44f1d@cornell.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <9bca5f61-1090-9a39-099a-13e4ed7a87ea@cs.ucla.edu> Date: Sat, 19 Aug 2017 15:38:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5b8f4814-a6bd-d373-f0e6-217845b44f1d@cornell.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 08/19/2017 03:04 PM, Ken Brown wrote: > > Is there any (good) reason that glibc doesn't provide a wrapper for > it? It seems that this would be pretty trivial to do. On the glibc side there has been a concern that it support a good GNU libc interface that does not assume a Linux kernel, as opposed to merely being a thin wrapper around whatever system calls Linux happens to provide. I don't know what the specific objections to renameat2 are, though. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 19 22:37:58 2017 Received: (at 27986) by debbugs.gnu.org; 20 Aug 2017 02:37:58 +0000 Received: from localhost ([127.0.0.1]:45987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djG7h-0002pR-S5 for submit@debbugs.gnu.org; Sat, 19 Aug 2017 22:37:58 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47626) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1djG7g-0002pE-Gv for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 22:37:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djG7X-0000J3-Tj for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 22:37:51 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djG7X-0000Iv-Pf for 27986@debbugs.gnu.org; Sat, 19 Aug 2017 22:37:47 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3833 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1djG7Q-0004XS-K6; Sat, 19 Aug 2017 22:37:41 -0400 Date: Sun, 20 Aug 2017 05:37:33 +0300 Message-Id: <83wp5zc6c2.fsf@gnu.org> From: Eli Zaretskii To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sat, 19 Aug 2017 17:33:56 -0400) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Richard Stallman > Date: Sat, 19 Aug 2017 17:33:56 -0400 > > > Btw, in case it isn't clear: the issue at hand is an incompatible > > change to rename-file (and probably also other functions, like > > copy-file). Where previously (rename-file A B) with B a directory > > will move A into B/A, under the proposed change it will only do so if > > B actually ended in a slash; otherwise it will move A to B, deleting B > > if it exists. The incompatibility will manifest itself if some old > > code expects to get B/A, but instead gets either an error (if B is a > > non-empty directory) or B silently removed (if it is empty). > > Assuming this applies only when directory B is empty, so that this > won't delete non-empty directories, then I don't have any objection. > I would object to deleting non-empty directories here. > > Another option that might be good is to make this operation always > signal an error in the case where B is a directory and does not end > with a slash. > > I don't have an opinion about which of those two is better. Thanks. I do indeed think that making this an error even if B is an empty directory would be better, as it will reveal the cases that need to be fixed more prominently. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 25 16:43:24 2017 Received: (at 27986) by debbugs.gnu.org; 25 Aug 2017 20:43:25 +0000 Received: from localhost ([127.0.0.1]:55110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dlLRo-0004o5-Oh for submit@debbugs.gnu.org; Fri, 25 Aug 2017 16:43:24 -0400 Received: from mail-pg0-f50.google.com ([74.125.83.50]:37864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dlLRi-0004nm-Qc for 27986@debbugs.gnu.org; Fri, 25 Aug 2017 16:43:19 -0400 Received: by mail-pg0-f50.google.com with SMTP id 83so4627872pgb.4 for <27986@debbugs.gnu.org>; Fri, 25 Aug 2017 13:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mime-version; bh=URewQ+WGGuYA2Hon3xVIqqaZ7uuOTUZpu1/I3cHLcQM=; b=nlOg0aHuee6CM06eTzzTwd6irBiZvXNF24bDBwq/orP9KjcJNKEkQbBpxF+RaSg587 v2K+Z1qJE9nA+bFy5KZKOw3EgSgT0DkrXpm66ikBM2wL+dUg1Pk8A++X9Q3wd3A+RbHg Mfg9dMtP7c2OiS/jWMi/i6nHdDPpp/Pvv9QgN4v8LR+kETUn+4YkzOKmgHm5F8jX/XpD W9MLaTNYk9HC1yL1/Ax2Kc97UCt9oW9Viw1sjifcSC3AYdD+yXNKN51DsefVgjl8tg6D LTjKL8EYhJpmsASNB3tYuYEw4EqJD1eJD9tyIX+Vm75HCC0XWyclnmH/J86opolmmuJ0 1BZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :references:user-agent:mime-version; bh=URewQ+WGGuYA2Hon3xVIqqaZ7uuOTUZpu1/I3cHLcQM=; b=o9iUrwSPAjexmXBeOw8f7kwE6GLlaxa7+LVGWfuEcongTqjHri7nOhe81ywWGk1pqs YYxND5Hc9sGMmdTE7SzV7CMHv/6IN1Z+wcFOTlNm4z7mX730bMbows8gQo7DHEJIRHG7 SnMUkZRFUB3I5ewnfBMlvRFLETGscq+U4jMM86WbwtpsWIeKzxRFyxje1OWU1SZM+wJK XxHE7Sp0Kop40PNP91jDG9+TV3kK+2KZMgEiV/kDC0LRpSWSfEHCUW/EA9sbf6N5B1Mj LYj0DBC6U+mneT6q0q/D78IsS0/eOsWpQwosvdedB7Q22Ew5Ujex0FUxwMdPqvF4u1/7 pdVw== X-Gm-Message-State: AHYfb5iFEbzr9ctiJKVfsZmf0RFX2DmDh5TZLUjGnZ9DYq/sy/I1XCe6 7gYgtB6MAIMMLaQ2iGo= X-Received: by 10.98.103.14 with SMTP id b14mr5522287pfc.171.1503693788389; Fri, 25 Aug 2017 13:43:08 -0700 (PDT) Received: from Vulcan.local (76-234-69-149.lightspeed.frokca.sbcglobal.net. [76.234.69.149]) by smtp.gmail.com with ESMTPSA id g26sm12725553pfk.139.2017.08.25.13.43.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Aug 2017 13:43:06 -0700 (PDT) From: John Wiegley X-Google-Original-From: "John Wiegley" Received: by Vulcan.local (Postfix, from userid 501) id CBCC38A339DD; Fri, 25 Aug 2017 13:43:05 -0700 (PDT) To: Eli Zaretskii Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without In-Reply-To: <83wp5zc6c2.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 20 Aug 2017 05:37:33 +0300") Date: Fri, 25 Aug 2017 13:33:46 -0700 Message-ID: References: <83wp5zc6c2.fsf@gnu.org> User-Agent: Gnus/5.130016 (Ma Gnus v0.16) Emacs/25.2.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org, rms@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) >>>>> "EZ" == Eli Zaretskii writes: EZ> Thanks. I do indeed think that making this an error even if B is an empty EZ> directory would be better, as it will reveal the cases that need to be EZ> fixed more prominently. I prefer that to renaming a directory when the target is a directory. That's not how /bin/mv behaves, so I'd be surprised if (rename-file) did differently. Making the Emacs version more restrictive, however, makes sense. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 26 03:31:29 2017 Received: (at 27986) by debbugs.gnu.org; 26 Aug 2017 07:31:29 +0000 Received: from localhost ([127.0.0.1]:55822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dlVZ3-0006mK-KO for submit@debbugs.gnu.org; Sat, 26 Aug 2017 03:31:29 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35205) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dlVZ1-0006m6-SO for 27986@debbugs.gnu.org; Sat, 26 Aug 2017 03:31:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dlVYu-0000PF-70 for 27986@debbugs.gnu.org; Sat, 26 Aug 2017 03:31:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dlVYu-0000P9-3Y; Sat, 26 Aug 2017 03:31:20 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4346 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dlVYg-0002yO-Hl; Sat, 26 Aug 2017 03:31:07 -0400 Date: Sat, 26 Aug 2017 10:30:57 +0300 Message-Id: <8360da7pla.fsf@gnu.org> From: Eli Zaretskii To: John Wiegley In-reply-to: (message from John Wiegley on Fri, 25 Aug 2017 13:33:46 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without References: <83wp5zc6c2.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org, rms@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: John Wiegley > Cc: rms@gnu.org, 27986@debbugs.gnu.org > Date: Fri, 25 Aug 2017 13:33:46 -0700 > > >>>>> "EZ" == Eli Zaretskii writes: > > EZ> Thanks. I do indeed think that making this an error even if B is an empty > EZ> directory would be better, as it will reveal the cases that need to be > EZ> fixed more prominently. > > I prefer that to renaming a directory when the target is a directory. That's > not how /bin/mv behaves, so I'd be surprised if (rename-file) did differently. > Making the Emacs version more restrictive, however, makes sense. Thanks. Paul, it sounds like we have a consensus on this, so please go ahead with the changes. At least Richard, John, and myself prefer to signal an error even when the target is an empty directory, so I hope the non-interactive rename-file could do that after your changes. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 10 18:49:18 2017 Received: (at 27986) by debbugs.gnu.org; 10 Sep 2017 22:49:18 +0000 Received: from localhost ([127.0.0.1]:59928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drB2S-0003xK-Hj for submit@debbugs.gnu.org; Sun, 10 Sep 2017 18:49:18 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:41174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drB2Q-0003x3-8c for 27986@debbugs.gnu.org; Sun, 10 Sep 2017 18:49:14 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4CD2B160CBF; Sun, 10 Sep 2017 15:49:07 -0700 (PDT) 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 LHxIt5nxFNjd; Sun, 10 Sep 2017 15:49:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 79710160AEA; Sun, 10 Sep 2017 15:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 IqzKwMkEskPg; Sun, 10 Sep 2017 15:49:06 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 3AEB3160A30; Sun, 10 Sep 2017 15:49:06 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii , Stefan Monnier 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> <83efs8dp4b.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Sun, 10 Sep 2017 15:49:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <83efs8dp4b.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27986 Cc: 27986@debbugs.gnu.org, p.stephani2@gmail.com, johnw@gnu.org, rms@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) OK, I installed the patch into the master branch. Also, I reviewed all calls to the affected functions and have a few followup patches that I plan to install separately soon, and mention here as I do. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 11 02:07:45 2017 Received: (at 27986-done) by debbugs.gnu.org; 11 Sep 2017 06:07:45 +0000 Received: from localhost ([127.0.0.1]:60273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drHsm-0007Wc-Tm for submit@debbugs.gnu.org; Mon, 11 Sep 2017 02:07:45 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drHsl-0007WO-7v for 27986-done@debbugs.gnu.org; Mon, 11 Sep 2017 02:07:44 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 99092160CE4; Sun, 10 Sep 2017 23:07:36 -0700 (PDT) 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 pyFXqmPrwibU; Sun, 10 Sep 2017 23:07:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0B49A160CE5; Sun, 10 Sep 2017 23:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 o8YSVk5s6tOg; Sun, 10 Sep 2017 23:07:34 -0700 (PDT) Received: from [192.168.1.9] (unknown [47.153.184.153]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id BF2A2160A7A; Sun, 10 Sep 2017 23:07:34 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation From: Paul Eggert To: Eli Zaretskii , Stefan Monnier 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> <83efs8dp4b.fsf@gnu.org> Organization: UCLA Computer Science Department Message-ID: <2ff8e814-b75d-1c9f-a096-8ad644c01ccc@cs.ucla.edu> Date: Sun, 10 Sep 2017 23:07:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------56432C9621D5BF0AA3AE3BCD" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27986-done Cc: p.stephani2@gmail.com, johnw@gnu.org, Michael Albinus , rms@gnu.org, 27986-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a multi-part message in MIME format. --------------56432C9621D5BF0AA3AE3BCD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Paul Eggert wrote: > I reviewed all calls to the affected functions and have a few followup = patches=20 > that I plan to install separately soon, and mention here as I do. I installed the patches (attached). Closing the bug report. I'll CC: this to Michael, as the last patch is to the Tramp tests, and he= may=20 want Tramp to become consistent with the new behavior for rename-file etc= . --------------56432C9621D5BF0AA3AE3BCD Content-Type: text/x-patch; name="0001-Make-copy-directory-act-like-copy-file-etc.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Make-copy-directory-act-like-copy-file-etc.patch" =46rom e22794867d878d53675fcc91d2ef1ad2494a2ff2 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 Sep 2017 22:07:30 -0700 Subject: [PATCH 1/6] Make copy-directory act like copy-file etc. Do the special dance with the destination only if it is a directory name, for consistency with copy-file etc. (Bug#27986). * doc/emacs/files.texi (Copying and Naming): * doc/lispref/files.texi (Create/Delete Dirs): * etc/NEWS: Document this. * lisp/files.el (copy-directory): Treat NEWNAME as special only if it is a directory name. --- doc/emacs/files.texi | 8 ++++---- doc/lispref/files.texi | 5 +++-- etc/NEWS | 4 ++-- lisp/files.el | 22 ++++++++++------------ 4 files changed, 19 insertions(+), 20 deletions(-) diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi index 0cf46b6..ca4f223 100644 --- a/doc/emacs/files.texi +++ b/doc/emacs/files.texi @@ -1572,10 +1572,10 @@ Copying and Naming =20 @findex copy-directory @kbd{M-x copy-directory} copies directories, similar to the -@command{cp -r} shell command. If @var{new} is an existing directory, -it creates a copy of the @var{old} directory and puts it in @var{new}. -If @var{new} is not an existing directory, it copies all the contents -of @var{old} into a new directory named @var{new}. +@command{cp -r} shell command. If @var{new} is a directory name, it +creates a copy of the @var{old} directory and puts it in @var{new}. +Otherwise it copies all the contents of @var{old} into a new directory +named @var{new}. =20 @cindex renaming files @findex rename-file diff --git a/doc/lispref/files.texi b/doc/lispref/files.texi index eacaf04..901382f 100644 --- a/doc/lispref/files.texi +++ b/doc/lispref/files.texi @@ -2976,8 +2976,9 @@ Create/Delete Dirs =20 @deffn Command copy-directory dirname newname &optional keep-time parent= s copy-contents This command copies the directory named @var{dirname} to -@var{newname}. If @var{newname} names an existing directory, +@var{newname}. If @var{newname} is a directory name, @var{dirname} will be copied to a subdirectory there. +@xref{Directory Names}. =20 It always sets the file modes of the copied files to match the corresponding original file. @@ -2992,7 +2993,7 @@ Create/Delete Dirs =20 The fifth argument @var{copy-contents}, if non-@code{nil}, means to copy the contents of @var{dirname} directly into @var{newname} if the -latter is an existing directory, instead of copying @var{dirname} into +latter is a directory name, instead of copying @var{dirname} into it as a subdirectory. @end deffn =20 diff --git a/etc/NEWS b/etc/NEWS index 4187dd8..136d458 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1285,8 +1285,8 @@ documentation and had inherent races that led to se= curity holes. A call like (rename-file C D) that used the old, undocumented behavior can be written as (rename-file C (file-name-as-directory D)), a formulation portable to both older and newer versions of Emacs. -Affected functions include add-name-to-file, copy-file, -make-symbolic-link, and rename-file. +Affected functions include add-name-to-file, copy-directory, +copy-file, make-symbolic-link, and rename-file. =20 =0C * Lisp Changes in Emacs 26.1 diff --git a/lisp/files.el b/lisp/files.el index 85e649f..7ab6f76 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -5501,10 +5501,10 @@ copy-directory create parent directories if they don't exist. Interactively, this happens by default. =20 -If NEWNAME names an existing directory, copy DIRECTORY as a -subdirectory there. However, if called from Lisp with a non-nil -optional argument COPY-CONTENTS, copy the contents of DIRECTORY -directly into NEWNAME instead." +If NEWNAME is a directory name, copy DIRECTORY as a subdirectory +there. However, if called from Lisp with a non-nil optional +argument COPY-CONTENTS, copy the contents of DIRECTORY directly +into NEWNAME instead." (interactive (let ((dir (read-directory-name "Copy directory: " default-directory default-directory t nil))) @@ -5526,19 +5526,17 @@ copy-directory =20 ;; Compute target name. (setq directory (directory-file-name (expand-file-name directory))= - newname (directory-file-name (expand-file-name newname))) + newname (expand-file-name newname)) =20 - (cond ((not (file-directory-p newname)) - ;; If NEWNAME is not an existing directory, create it; + (cond ((not (directory-name-p newname)) + ;; If NEWNAME is not a directory name, create it; ;; that is where we will copy the files of DIRECTORY. (make-directory newname parents)) - ;; If NEWNAME is an existing directory and COPY-CONTENTS + ;; If NEWNAME is a directory name and COPY-CONTENTS ;; is nil, copy into NEWNAME/[DIRECTORY-BASENAME]. ((not copy-contents) - (setq newname (concat - (file-name-as-directory newname) - (file-name-nondirectory - (directory-file-name directory)))) + (setq newname (concat newname + (file-name-nondirectory directory))) (and (file-exists-p newname) (not (file-directory-p newname)) (error "Cannot overwrite non-directory %s with a directory" --=20 2.7.4 --------------56432C9621D5BF0AA3AE3BCD Content-Type: text/x-patch; name="0002-Make-write-file-act-like-copy-file-etc.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0002-Make-write-file-act-like-copy-file-etc.patch" =46rom 61946d991b663c9d35a50b758d0108c3cbf8027b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 Sep 2017 22:19:01 -0700 Subject: [PATCH 2/6] Make write-file act like copy-file etc. Change write-file to be consistent with the new behavior of copy-file, etc. * etc/NEWS: Mention this. * lisp/files.el (write-file): Treat the destination as special only if it is a directory name. --- etc/NEWS | 3 ++- lisp/files.el | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 136d458..4da4c37 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1286,7 +1286,8 @@ call like (rename-file C D) that used the old, undo= cumented behavior can be written as (rename-file C (file-name-as-directory D)), a formulation portable to both older and newer versions of Emacs. Affected functions include add-name-to-file, copy-directory, -copy-file, make-symbolic-link, and rename-file. +copy-file, format-write-file, make-symbolic-link, rename-file, and +write-file. =20 =0C * Lisp Changes in Emacs 26.1 diff --git a/lisp/files.el b/lisp/files.el index 7ab6f76..611a4c5 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -4212,10 +4212,10 @@ write-file (not current-prefix-arg))) (or (null filename) (string-equal filename "") (progn - ;; If arg is just a directory, + ;; If arg is a directory name, ;; use the default file name, but in that directory. - (if (file-directory-p filename) - (setq filename (concat (file-name-as-directory filename) + (if (directory-name-p filename) + (setq filename (concat filename (file-name-nondirectory (or buffer-file-name (buffer-name)))))) (and confirm --=20 2.7.4 --------------56432C9621D5BF0AA3AE3BCD Content-Type: text/x-patch; name="0003-Make-gnus-copy-file-act-like-copy-file-etc.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0003-Make-gnus-copy-file-act-like-copy-file-etc.patch" =46rom 739593d68742f45e4e35dfc99573c47a5031b646 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 Sep 2017 22:21:20 -0700 Subject: [PATCH 3/6] Make gnus-copy-file act like copy-file etc. * etc/NEWS: Mention this. * lisp/gnus/gnus-util.el (gnus-copy-file): Treat the destination as special only if it is a directory name. --- etc/NEWS | 4 ++-- lisp/gnus/gnus-util.el | 3 --- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 4da4c37..fc40a3a 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1286,8 +1286,8 @@ call like (rename-file C D) that used the old, undo= cumented behavior can be written as (rename-file C (file-name-as-directory D)), a formulation portable to both older and newer versions of Emacs. Affected functions include add-name-to-file, copy-directory, -copy-file, format-write-file, make-symbolic-link, rename-file, and -write-file. +copy-file, format-write-file, gnus-copy-file, make-symbolic-link, +rename-file, and write-file. =20 =0C * Lisp Changes in Emacs 26.1 diff --git a/lisp/gnus/gnus-util.el b/lisp/gnus/gnus-util.el index b509d8a..93541f0 100644 --- a/lisp/gnus/gnus-util.el +++ b/lisp/gnus/gnus-util.el @@ -594,9 +594,6 @@ gnus-copy-file (read-file-name "Copy file to: " default-directory))) (unless to (setq to (read-file-name "Copy file to: " default-directory))) - (when (file-directory-p to) - (setq to (concat (file-name-as-directory to) - (file-name-nondirectory file)))) (copy-file file to)) =20 (defvar gnus-work-buffer " *gnus work*") --=20 2.7.4 --------------56432C9621D5BF0AA3AE3BCD Content-Type: text/x-patch; name="0004-Adjust-ob-tangle-to-new-copy-file-behavior.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0004-Adjust-ob-tangle-to-new-copy-file-behavior.patch" =46rom 74b8615fcceba7b92c4938e1bcc92015f10ae899 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 Sep 2017 22:22:55 -0700 Subject: [PATCH 4/6] Adjust ob-tangle to new copy-file behavior * lisp/org/ob-tangle.el (org-babel-tangle-publish): Port to new copy-file behavior. --- lisp/org/ob-tangle.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/org/ob-tangle.el b/lisp/org/ob-tangle.el index 3b05332..2dc55ca 100644 --- a/lisp/org/ob-tangle.el +++ b/lisp/org/ob-tangle.el @@ -197,6 +197,7 @@ org-babel-tangle-publish "Tangle FILENAME and place the results in PUB-DIR." (unless (file-exists-p pub-dir) (make-directory pub-dir t)) + (setq pub-dir (file-name-as-directory pub-dir)) (mapc (lambda (el) (copy-file el pub-dir t)) (org-babel-tangle-file fi= lename))) =20 ;;;###autoload --=20 2.7.4 --------------56432C9621D5BF0AA3AE3BCD Content-Type: text/x-patch; name="0005-Adjust-thumbs-to-new-rename-file-behavior.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0005-Adjust-thumbs-to-new-rename-file-behavior.patch" =46rom 2aa028825920207cca2bacb581111ab780e5d9ee Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 Sep 2017 22:28:08 -0700 Subject: [PATCH 5/6] Adjust thumbs to new rename-file behavior * etc/NEWS: Mention this. * lisp/thumbs.el (thumbs-rename-images): Treat the destination as special only if it is a directory name. When there is a marked list, turn the destination into a directory name if it is not already. --- etc/NEWS | 2 +- lisp/thumbs.el | 15 ++++----------- 2 files changed, 5 insertions(+), 12 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index fc40a3a..3f1df23 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1287,7 +1287,7 @@ can be written as (rename-file C (file-name-as-dire= ctory D)), a formulation portable to both older and newer versions of Emacs. Affected functions include add-name-to-file, copy-directory, copy-file, format-write-file, gnus-copy-file, make-symbolic-link, -rename-file, and write-file. +rename-file, thumbs-rename-images, and write-file. =20 =0C * Lisp Changes in Emacs 26.1 diff --git a/lisp/thumbs.el b/lisp/thumbs.el index 0665429..d0b5e22 100644 --- a/lisp/thumbs.el +++ b/lisp/thumbs.el @@ -523,23 +523,16 @@ thumbs-rename-images (interactive "FRename to file or directory: ") (let ((files (or thumbs-marked-list (list (thumbs-current-image)))) failures) - (if (and (not (file-directory-p newfile)) - thumbs-marked-list) - (if (file-exists-p newfile) - (error "Renaming marked files to file name `%s'" newfile) - (make-directory newfile t))) + (when thumbs-marked-list + (make-directory newfile t) + (setq newfile (file-name-as-directory newfile))) (if (yes-or-no-p (format "Really rename %d files? " (length files)))= (let ((thumbs-file-list (thumbs-file-alist)) (inhibit-read-only t)) (dolist (file files) (let (failure) (condition-case () - (if (file-directory-p newfile) - (rename-file file - (expand-file-name - (file-name-nondirectory file) - newfile)) - (rename-file file newfile)) + (rename-file file newfile) (file-error (setq failure t) (push file failures))) (unless failure --=20 2.7.4 --------------56432C9621D5BF0AA3AE3BCD Content-Type: text/x-patch; name="0006-Port-tramp-tests-to-new-copy-directory-behavior.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="0006-Port-tramp-tests-to-new-copy-directory-behavior.patch" =46rom 29963648dd11d53088f753e4f9b0491a7b981c0f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 10 Sep 2017 23:04:10 -0700 Subject: [PATCH 6/6] Port tramp-tests to new copy-directory behavior * test/lisp/net/tramp-tests.el (tramp-test15-copy-directory): Use directory name as arg for copy-directory when we want the special behavior. --- test/lisp/net/tramp-tests.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/test/lisp/net/tramp-tests.el b/test/lisp/net/tramp-tests.el index 735211c..4139d50 100644 --- a/test/lisp/net/tramp-tests.el +++ b/test/lisp/net/tramp-tests.el @@ -2117,7 +2117,7 @@ tramp--test-backtrace (should (file-directory-p tmp-name2)) (should (file-exists-p tmp-name5)) ;; Target directory does exist already. - (copy-directory tmp-name1 tmp-name2) + (copy-directory tmp-name1 (file-name-as-directory tmp-name2)) (should (file-directory-p tmp-name3)) (should (file-exists-p tmp-name6))) =20 @@ -2140,7 +2140,8 @@ tramp--test-backtrace ;; Target directory does exist already. (delete-file tmp-name5) (should-not (file-exists-p tmp-name5)) - (copy-directory tmp-name1 tmp-name2 nil 'parents 'contents) + (copy-directory tmp-name1 (file-name-as-directory tmp-name2) + nil 'parents 'contents) (should (file-directory-p tmp-name2)) (should (file-exists-p tmp-name5)) (should-not (file-directory-p tmp-name3)) --=20 2.7.4 --------------56432C9621D5BF0AA3AE3BCD-- From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 11 10:47:56 2017 Received: (at 27986) by debbugs.gnu.org; 11 Sep 2017 14:47:56 +0000 Received: from localhost ([127.0.0.1]:33613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drQ0C-0005GV-3W for submit@debbugs.gnu.org; Mon, 11 Sep 2017 10:47:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drQ0A-0005GH-5G for 27986@debbugs.gnu.org; Mon, 11 Sep 2017 10:47:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drQ00-0004T1-Cz for 27986@debbugs.gnu.org; Mon, 11 Sep 2017 10:47:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drPzr-0004NN-OP; Mon, 11 Sep 2017 10:47:35 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4315 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1drPzk-0000tW-MC; Mon, 11 Sep 2017 10:47:29 -0400 Date: Mon, 11 Sep 2017 17:47:26 +0300 Message-Id: <8360cpthq9.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: <2ff8e814-b75d-1c9f-a096-8ad644c01ccc@cs.ucla.edu> (message from Paul Eggert on Sun, 10 Sep 2017 23:07:34 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> <83efs8dp4b.fsf@gnu.org> <2ff8e814-b75d-1c9f-a096-8ad644c01ccc@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: rms@gnu.org, johnw@gnu.org, p.stephani2@gmail.com, michael.albinus@gmx.de, monnier@IRO.UMontreal.CA, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Paul Eggert > Cc: johnw@gnu.org, rms@gnu.org, p.stephani2@gmail.com, > 27986-done@debbugs.gnu.org, Michael Albinus > Date: Sun, 10 Sep 2017 23:07:34 -0700 > > Paul Eggert wrote: > > I reviewed all calls to the affected functions and have a few followup patches > > that I plan to install separately soon, and mention here as I do. > > I installed the patches (attached). Closing the bug report. Am I missing something, or do these changes modify interactive behavior in incompatible ways? I thought we agreed to leave the interactive behavior intact, and only change the non-interactive uses. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 11 12:45:58 2017 Received: (at 27986) by debbugs.gnu.org; 11 Sep 2017 16:45:58 +0000 Received: from localhost ([127.0.0.1]:33846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drRqO-0008By-TG for submit@debbugs.gnu.org; Mon, 11 Sep 2017 12:45:58 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:38496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drRqN-0008Bl-DK for 27986@debbugs.gnu.org; Mon, 11 Sep 2017 12:45:55 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BFAD4160CE4; Mon, 11 Sep 2017 09:45:49 -0700 (PDT) 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 v_55UqsCWmmP; Mon, 11 Sep 2017 09:45:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EAA0F160CC8; Mon, 11 Sep 2017 09:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 JjnCBPkD3nAY; Mon, 11 Sep 2017 09:45:48 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id CA8A316096F; Mon, 11 Sep 2017 09:45:48 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> <83efs8dp4b.fsf@gnu.org> <2ff8e814-b75d-1c9f-a096-8ad644c01ccc@cs.ucla.edu> <8360cpthq9.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Mon, 11 Sep 2017 09:45:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8360cpthq9.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27986 Cc: rms@gnu.org, johnw@gnu.org, p.stephani2@gmail.com, michael.albinus@gmx.de, monnier@IRO.UMontreal.CA, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On 09/11/2017 07:47 AM, Eli Zaretskii wrote: > do these changes modify interactive > behavior in incompatible ways? I thought we agreed to leave the > interactive behavior intact, and only change the non-interactive uses. > That wasn't my understanding. In our last email exchange about interactivity I proposed that Emacs prompt the user when the destination is not a directory name but happens to be a directory (see Bug#27986#97), but you were dubious about that (Bug#27986#100) so I left it alone. I normally use dired to rename files in Emacs, and dired's behavior hasn't changed as far as I can tell. Where there is a bit of a change is when using M-x rename-file directly. Here, in the typical case with file name completion there is still no difference, since names of destination directories are completed to have trailing /. However, if one uses "M-x rename-file foo RET and then laboriously types out the name of an existing directory /tmp/destination-dir without using completion and without trailing / before hitting RET, one will notice a difference: rename-file will now say "File /tmp/destination-dir already exists; rename to it anyway? (yes or no)" and if one types "yes" the rename will typically fail. So yes, this is a (noisy) incompatibility with previous usage. If you like I can go back and implement the suggestion in Bug#27986#97; this would be more-compatible with existing usage. I suggest leaving it alone, though, as things are simpler and easier to explain the way they are. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 11 13:10:25 2017 Received: (at 27986) by debbugs.gnu.org; 11 Sep 2017 17:10:25 +0000 Received: from localhost ([127.0.0.1]:33895 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drSE4-0000LR-Oj for submit@debbugs.gnu.org; Mon, 11 Sep 2017 13:10:25 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42397) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drSE3-0000LG-Gu for 27986@debbugs.gnu.org; Mon, 11 Sep 2017 13:10:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drSDs-0002eN-7M for 27986@debbugs.gnu.org; Mon, 11 Sep 2017 13:10:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35894) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drSDe-0002WH-0W; Mon, 11 Sep 2017 13:09:58 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4649 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1drSDW-0000rE-SZ; Mon, 11 Sep 2017 13:09:51 -0400 Date: Mon, 11 Sep 2017 20:09:48 +0300 Message-Id: <83efrdrwkj.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: (message from Paul Eggert on Mon, 11 Sep 2017 09:45:48 -0700) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> <83efs8dp4b.fsf@gnu.org> <2ff8e814-b75d-1c9f-a096-8ad644c01ccc@cs.ucla.edu> <8360cpthq9.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 27986 Cc: rms@gnu.org, johnw@gnu.org, p.stephani2@gmail.com, michael.albinus@gmx.de, monnier@IRO.UMontreal.CA, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: monnier@IRO.UMontreal.CA, johnw@gnu.org, rms@gnu.org, > p.stephani2@gmail.com, 27986@debbugs.gnu.org, michael.albinus@gmx.de > From: Paul Eggert > Date: Mon, 11 Sep 2017 09:45:48 -0700 > > On 09/11/2017 07:47 AM, Eli Zaretskii wrote: > > do these changes modify interactive > > behavior in incompatible ways? I thought we agreed to leave the > > interactive behavior intact, and only change the non-interactive uses. > > > That wasn't my understanding. In our last email exchange about > interactivity I proposed that Emacs prompt the user when the destination > is not a directory name but happens to be a directory (see > Bug#27986#97), but you were dubious about that (Bug#27986#100) so I left > it alone. > > I normally use dired to rename files in Emacs, and dired's behavior > hasn't changed as far as I can tell. Where there is a bit of a change is > when using M-x rename-file directly. Here, in the typical case with file > name completion there is still no difference, since names of destination > directories are completed to have trailing /. However, if one uses "M-x > rename-file foo RET and then laboriously types out the name of an > existing directory /tmp/destination-dir without using completion and > without trailing / before hitting RET, one will notice a difference: > rename-file will now say "File /tmp/destination-dir already exists; > rename to it anyway? (yes or no)" and if one types "yes" the rename will > typically fail. So yes, this is a (noisy) incompatibility with previous > usage. If you like I can go back and implement the suggestion in > Bug#27986#97; this would be more-compatible with existing usage. I > suggest leaving it alone, though, as things are simpler and easier to > explain the way they are. I think there was a confusion here between interactive and non-interactive uses of rename-file. For interactive use, AFAIR we agreed that the behavior should stay as before, in particular to be consistent with e.g. invocation of 'mv' from the shell prompt. For non-interactive use, we agreed to change the behavior wrt directories, with a slight preference to signaling an error even if the target is an empty directory. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 11 13:25:34 2017 Received: (at 27986) by debbugs.gnu.org; 11 Sep 2017 17:25:34 +0000 Received: from localhost ([127.0.0.1]:33921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drSSk-0000jH-E1 for submit@debbugs.gnu.org; Mon, 11 Sep 2017 13:25:34 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drSSi-0000j5-VE for 27986@debbugs.gnu.org; Mon, 11 Sep 2017 13:25:33 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4F29E160CE7; Mon, 11 Sep 2017 10:25:26 -0700 (PDT) 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 e1ZcO4muKrBb; Mon, 11 Sep 2017 10:25:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 88231160CEA; Mon, 11 Sep 2017 10:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu 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 DEb7_ATJnSGX; Mon, 11 Sep 2017 10:25:25 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 66EA01600DE; Mon, 11 Sep 2017 10:25:25 -0700 (PDT) Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation To: Eli Zaretskii 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> <83efs8dp4b.fsf@gnu.org> <2ff8e814-b75d-1c9f-a096-8ad644c01ccc@cs.ucla.edu> <8360cpthq9.fsf@gnu.org> <83efrdrwkj.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <0db4d790-81de-de02-074b-71308d729d2d@cs.ucla.edu> Date: Mon, 11 Sep 2017 10:25:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <83efrdrwkj.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 27986 Cc: rms@gnu.org, johnw@gnu.org, p.stephani2@gmail.com, michael.albinus@gmx.de, monnier@IRO.UMontreal.CA, 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On 09/11/2017 10:09 AM, Eli Zaretskii wrote: > I think there was a confusion here between interactive and > non-interactive uses of rename-file. For interactive use, AFAIR we > agreed that the behavior should stay as before, in particular to be > consistent with e.g. invocation of 'mv' from the shell prompt. That wasn't my understanding, and the email record is consistent with my interpretation. Although we discussed mv, the last comment on that topic was from John, who wrote about mv that "Making the Emacs version more restrictive, however, makes sense" (Bug#27986#145). This corresponds to the patch I installed, whose rename-file is more restrictive than mv because it balks at renaming a regular file F to G when G is not a directory name but happens to be an existing directory. As I wrote, I don't think this will matter much in practice because the point is moot when file name completion is used. If I'm wrong and it is a significant problem, I can still implement the suggestion in Bug#27986#97 to ameliorate it. It may be better, though, to try out what we have now for a while, to see whether that suggestion would actually help. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 12 05:26:19 2017 Received: (at 27986) by debbugs.gnu.org; 12 Sep 2017 09:26:19 +0000 Received: from localhost ([127.0.0.1]:34743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drhSV-0000OJ-Je for submit@debbugs.gnu.org; Tue, 12 Sep 2017 05:26:19 -0400 Received: from mout.gmx.net ([212.227.17.21]:56166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drhST-0000O5-AM for 27986@debbugs.gnu.org; Tue, 12 Sep 2017 05:26:17 -0400 Received: from detlef.gmx.de ([213.220.156.183]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MNO33-1dpEcM3DCL-006xUz; Tue, 12 Sep 2017 11:25:55 +0200 From: Michael Albinus To: Paul Eggert Subject: Re: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation 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> <83o9rffqfp.fsf@gnu.org> <83efsbfmij.fsf@gnu.org> <83efs8dp4b.fsf@gnu.org> <2ff8e814-b75d-1c9f-a096-8ad644c01ccc@cs.ucla.edu> Date: Tue, 12 Sep 2017 11:25:51 +0200 In-Reply-To: <2ff8e814-b75d-1c9f-a096-8ad644c01ccc@cs.ucla.edu> (Paul Eggert's message of "Sun, 10 Sep 2017 23:07:34 -0700") Message-ID: <87mv60feu8.fsf@detlef> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:cxDonT+Lv/Ya865miUGLBGUvl/FuMc4qU/JBAO+TNtV538FTp3m dF0fsN9Ls4LRkgVy88LX9albbQm508ky32M0MIu8xkGo9o0lkLtWqfOq6dOk89o9K2SfuoG e5agmiWDcp9Vi2KqpZ/Dj/buNqy6GDkNrSg+3JYd72ZLiTLo6ECb4sTNplbe1k4iFzVouW5 kcrFFrxJFl90dUfNE/3bQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:It7HTSFr8pE=:4vFx2CGxCDknBsaKP7GFxJ pjlgwpgJPTUkhnh9ck4pxLhW4lS8aeFpsV1Yl6qA3eQDRmRm5MBLUHQxUG4bSLaDy54HGglLe hizhFrSyFarR2q5kqIFG78aa9fuBxfkDTsoG1JuMMWFH/wxZpYG3wv6EH1YAQQG3oPyNh/xTJ eqYaoB1nnRkTGLoc9Tu/2cGWhqS8xo0msA8E1XGL4A2K/H9zh6Ss+J7UEBnspDYC49Jen+s8F htfpJiJ6fmwEOWETRvfiNvPDmtYMy+jPGbLjtEuFKVjz3bj/QeBM8NCPkgF3VDcJqWv0Oaggr nytD0KEE9w3Zf4jhIwRfSaxnXPxEanpW0yrKwsLMPglKo7klRLzsbgW+z2KisuNBNV+2igvyX 2Y2EMqTQ203x+IWLAG9CamiAiRj2LarQcGZQoPimgGbDpQEqSkqkocTn0WW/1aPMwxWFL8L99 WFdcPWEhIoTEQQEA7c0TYNSCK0C8C1tOXPDiJ58l9W1OEi0eEJJiAnBvK5VYhHM+6BnF6F4Ip H8RPkeSB2+jB8FxRG3/rfJm0mLuFwdtM7B2gU1zvg/IMkPyIoHwLsaMOT5OIfwbeQ9FlrfGq+ G76dZ//YpsgAWHszi8cKR0NFC83lcaIcB8i909rX8PeekKrsufQfDv+7D/xI0QNgl/d9Ddw/K VLgQ1V66sNKcI754KZRaCDHz9dFkfD1fXVQMMSI9JaClTospzE8D9pT3ee877bBWUmvTgqVeb +fjLnaIxMObBndd2e6sjcuc9O3d+AeRPF9gEqoSzd45HFrICyMPe0pcxT+bpnqkf7qQt/s+uc eF3YbvwMJhh+ebzP+LlWuO41o5bckEryAF4DURegCwG/utVZPU= X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 27986 Cc: rms@gnu.org, johnw@gnu.org, p.stephani2@gmail.com, Stefan Monnier , Eli Zaretskii , 27986@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) Paul Eggert writes: Hi Paul, > I'll CC: this to Michael, as the last patch is to the Tramp tests, and > he may want Tramp to become consistent with the new behavior for > rename-file etc. I've checked Tramp: it works already proper, thanks to Kai. At least for the methods handled in tramp-sh.el. Next days, I'll check also tramp-adb.el, tramp-gvfs.el, and tramp-smb.el. I've added some additional tests to tramp-tests.el, in order to provoke an error when a directory as target does not look like a directory name. Best regards, Michael. From unknown Mon Jun 23 02:21:16 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 10 Oct 2017 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator