From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: p.stephani2@gmail.com, 27986@debbugs.gnu.org
Subject: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation
Date: Mon, 14 Aug 2017 16:31:38 -0700 [thread overview]
Message-ID: <ac687681-5f4b-2f8e-97ff-9f3dcb425a11@cs.ucla.edu> (raw)
In-Reply-To: <83o9rignt6.fsf@gnu.org>
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: 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"), 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. I doubt whether this is the only
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
its documentation when B is an existing directory.
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.
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.
next prev parent reply other threads:[~2017-08-14 23:31 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-06 15:40 bug#27986: 26.0.50; `rename-file' can rename files without confirmation Philipp
2017-08-06 17:05 ` Eli Zaretskii
2017-08-14 17:09 ` Philipp Stephani
2017-08-14 17:22 ` Eli Zaretskii
2017-08-11 8:15 ` bug#27986: 26.0.50; 'rename-file' " Paul Eggert
2017-08-13 22:42 ` Paul Eggert
2017-08-14 15:40 ` Eli Zaretskii
2017-08-14 23:31 ` Paul Eggert [this message]
2017-08-15 16:04 ` Eli Zaretskii
2017-08-15 17:24 ` Paul Eggert
2017-08-15 17:42 ` Eli Zaretskii
2017-08-15 19:27 ` Paul Eggert
2017-08-16 2:36 ` Eli Zaretskii
2017-08-16 5:06 ` Paul Eggert
2017-08-16 14:21 ` Eli Zaretskii
2017-08-16 15:15 ` Paul Eggert
2017-08-16 16:06 ` Eli Zaretskii
2017-08-16 17:19 ` Paul Eggert
2017-08-16 17:30 ` Eli Zaretskii
2017-08-16 18:06 ` Glenn Morris
2017-08-16 22:31 ` Stefan Monnier
2017-08-16 23:56 ` Paul Eggert
2017-08-17 0:04 ` Stefan Monnier
2017-08-19 6:54 ` Eli Zaretskii
2017-09-10 22:49 ` Paul Eggert
2017-09-11 6:07 ` Paul Eggert
2017-09-11 14:47 ` Eli Zaretskii
2017-09-11 16:45 ` Paul Eggert
2017-09-11 17:09 ` Eli Zaretskii
2017-09-11 17:25 ` Paul Eggert
2017-09-12 9:25 ` Michael Albinus
2017-08-13 23:48 ` Paul Eggert
2017-08-14 13:44 ` Ken Brown
2017-08-14 15:21 ` Eli Zaretskii
2017-08-14 15:34 ` Eli Zaretskii
2017-08-14 16:33 ` Eli Zaretskii
2017-08-14 16:58 ` Philipp Stephani
2017-08-14 17:04 ` Eli Zaretskii
2017-08-14 16:50 ` Philipp Stephani
2017-08-14 23:03 ` Paul Eggert
2017-08-15 1:19 ` Paul Eggert
2017-08-15 2:35 ` Eli Zaretskii
2017-08-15 7:00 ` Paul Eggert
2017-08-15 16:08 ` Eli Zaretskii
2017-08-16 19:33 ` Ken Brown
2017-08-19 21:30 ` Ken Brown
2017-08-19 21:37 ` Paul Eggert
2017-08-19 22:04 ` Ken Brown
2017-08-19 22:38 ` Paul Eggert
2017-08-15 12:45 ` Andy Moreton
2017-08-15 16:18 ` Eli Zaretskii
2017-08-19 21:33 ` bug#27986: 26.0.50; 'rename-file' can rename files without Richard Stallman
2017-08-20 2:37 ` Eli Zaretskii
2017-08-25 20:33 ` John Wiegley
2017-08-26 7:30 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ac687681-5f4b-2f8e-97ff-9f3dcb425a11@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=27986@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=p.stephani2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.