From: Jim Porter <jporterbugs@gmail.com>
To: Ulrich Mueller <ulm@gentoo.org>, 51327@debbugs.gnu.org
Cc: Paul Eggert <eggert@cs.ucla.edu>
Subject: bug#51327: 28.0.60; emacsclient warns about XDG_RUNTIME_DIR when starting daemon on demand
Date: Thu, 11 Nov 2021 09:06:36 -0800 [thread overview]
Message-ID: <82a66db9-f9b3-fc0f-a98d-8900d4fec066@gmail.com> (raw)
In-Reply-To: <u7ddevo6y@gentoo.org>
On 11/11/2021 5:04 AM, Ulrich Mueller wrote:
>>>>>> On Fri, 05 Nov 2021, Ulrich Mueller wrote:
>
>>>>>> On Fri, 05 Nov 2021, Jim Porter wrote:
>>> I'm not an expert on this kind of attack, but my understanding is that
>>> it could go something like this:
>
>>> 1. Attacker runs `evil-daemon' which puts its socket in /tmp/evil
>>> 2. Attacker runs `ln -s /tmp/evil /tmp/emacs1000/server'
>
>> Right, and IIUC this must be carefully timed to exploit some race
>> condition between permission checking and creating the socket. I am
>> not an expert on this either.
>
> Thinking about it some more, when you always start the daemon with
> XDG_RUNTIME_DIR present, there won't be a /tmp/emacs1000/server (at
> least not one with correct user and permissions), and I don't believe
> that a symlink attack would be possible.
>
> OTOH, when you start the daemon without XDG_RUNTIME_DIR, then the socket
> will be created in /tmp, but in that case you'd want the client to find
> it there.
The case I'm concerned about is when the daemon *hasn't* been started
yet by the time emacsclient is called. In that case, emacsclient checks
both XDG_RUNTIME_DIR and TMPDIR before giving up and starting the
daemon. In this case, that means that even on a system where Emacs only
uses XDG_RUNTIME_DIR in practice, it'll still search TMPDIR the first
time when looking for the (non-existent) daemon. The question then is
whether it's safe for the emacsclient to look in TMPDIR to confirm that
no daemon already exists.
It's possible that this behavior is perfectly safe, but the way the code
is currently written (plus Paul Eggert's reply in this bug) seem to
indicate that it's vulnerable to attack. If it really is vulnerable,
then I think it should be fixed; if it's safe, then just eliminating the
warning is sufficient of course.
next prev parent reply other threads:[~2021-11-11 17:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-22 4:58 bug#51327: 28.0.60; emacsclient warns about XDG_RUNTIME_DIR when starting daemon on-demand Jim Porter
2021-10-30 19:37 ` Jim Porter
2021-10-30 22:33 ` Paul Eggert
2021-12-07 11:26 ` Stefan Kangas
2021-12-07 14:27 ` Eli Zaretskii
2021-12-07 14:58 ` Stefan Kangas
2021-12-07 19:03 ` Paul Eggert
2021-12-08 6:57 ` Jim Porter
2021-12-08 19:06 ` Paul Eggert
2021-12-08 19:16 ` Eli Zaretskii
2021-12-08 20:23 ` Stefan Kangas
2021-12-08 21:56 ` Ulrich Mueller
2021-12-08 22:56 ` Jim Porter
2021-12-08 23:44 ` Paul Eggert
2021-12-09 0:19 ` Ulrich Mueller
2021-12-09 7:32 ` Eli Zaretskii
2021-12-09 7:44 ` Ulrich Mueller
2021-12-09 17:12 ` Paul Eggert
2021-12-09 18:34 ` Eli Zaretskii
2021-12-09 19:45 ` Jim Porter
2021-12-09 19:48 ` Paul Eggert
2021-12-09 19:57 ` Eli Zaretskii
2021-12-09 20:04 ` Paul Eggert
2022-09-10 5:01 ` Lars Ingebrigtsen
2022-09-10 5:53 ` Paul Eggert via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-12-09 4:10 ` Richard Stallman
2021-11-05 10:38 ` bug#51327: 28.0.60; emacsclient warns about XDG_RUNTIME_DIR when starting daemon on demand Ulrich Mueller
2021-11-05 17:54 ` Jim Porter
2021-11-05 18:05 ` Ulrich Mueller
2021-11-05 18:38 ` Jim Porter
2021-11-05 19:02 ` Ulrich Mueller
2021-11-11 13:04 ` Ulrich Mueller
2021-11-11 17:06 ` Jim Porter [this message]
2021-11-12 2:21 ` Paul Eggert
2021-12-07 14:58 ` Stefan Kangas
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82a66db9-f9b3-fc0f-a98d-8900d4fec066@gmail.com \
--to=jporterbugs@gmail.com \
--cc=51327@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=ulm@gentoo.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).