bug#51327: 28.0.60; emacsclient warns about XDG_RUNTIME_DIR when starting daemon on-demand

[Jim Porter <jporterbugs@gmail.com>]

On 12/7/2021 11:03 AM, Paul Eggert wrote:
> Ulrich says the loophole is small because Emacs verifies that the 
> current user is the socket owner. However, small loopholes can still be 
> exploited: for example, an attacker could cause you to think that you're 
> connecting to your Emacs when you're really connecting to another of 
> your processes, and this could still lead to problems (particularly if 
> you're root).

While I understand that Ulrich's goal is for things to Just Work with 
Gentoo's app-emacs/emacs-daemon package (which puts the socket in 
$TMPDIR), it seems there's no way to get that without opening at least a 
small loophole.

When the user is guaranteed to be connecting to an Emacs daemon whose 
socket is in $TMPDIR, it's sufficient on Emacs 27 to just unset 
$XDG_RUNTIME_DIR first. However, from my discussion with Ulrich 
before[1], I believe one of the goals is to look in *both* places for a 
socket to be more flexible, as Emacs 28 currently does.

Doing that by default opens a loophole for all emacsclient users, but 
what about a command-line flag like `emacsclient 
--allow-tmpdir-loophole' and/or an environment variable like 
`EMACS_ALLOW_TMPDIR_LOOPHOLE=1 emacsclient' (with a better name, of 
course)? Then, the default behavior would be free of loopholes[2], but 
Ulrich's case could be achieved by passing that flag when calling 
emacsclient. It might even be possible for Gentoo to enable that for the 
user in the appropriate cases...

That's not as user-/distro-friendly as things just working 
automatically, but maybe it would be a decent compromise? Of course, if 
the loophole is small enough, maybe the current behavior in Emacs 28 is 
ok (aside from the warning message). I'm not an expert on the security 
implications though, so I don't have a strong opinion on which way to go 
here.

[1] https://lists.gnu.org/archive/html/emacs-devel/2021-11/msg00435.html
[2] Well, *known* loopholes...