bug#33847: 27.0.50; emacsclient does not find server socket

[Ulrich Mueller <ulm@gentoo.org>]

>>>>> On Wed, 26 Dec 2018, Paul Eggert wrote:

>> IMHO that's not an acceptable solution. emacsclient should just work in
>> the default configuration, without requiring the user to jump through
>> hoops, and an Emacs daemon should persist between sessions (otherwise
>> "daemon" would be a misnomer). Or is that use case really so uncommon?

> We have a conflict here between "just work" and security. There are
> multiple workarounds for the problem that you mention; if none of them
> are convenient enough perhaps you can suggest a more-convenient one.

IMHO, unsetting a standard variable like XDG_RUNTIME_DIR (as you've
suggested above) in the user's session isn't really an option. And a
wrapper script around emacsclient would be just awkward.

Plus, as it is currently implemented, there isn't even a unique way to
override the socket's location. I notice that emacsclient will now
honour the EMACS_SOCKET_NAME variable, but then again, server.el doesn't
use it. So if we would want to override the socket's location at the
distro level (e.g., place it in /run/emacs/${USER}/), how could we do
that? Having to add configuration to both site-start.el and to the
user's environment seems less than optimal.

> The default should be secure, though.

If it is a security issue, then why isn't the fix in the emacs-26 branch
as well? Also, why is there still a fallback to TMPDIR, if that's
considered insecure?

>> if there is a security problem, how would it disappear by moving
>> the socket to XDG_RUNTIME_DIR? Note that other tools like "screen" also
>> place their sockets in a subdir of /tmp.

> XDG_RUNTIME_DIR is guaranteed to be a directory owned by the user and
> readable and writable by nobody else. /tmp/emacsUID does not have that
> property.

XDG_RUNTIME_DIR is simply not suitable for the purpose, because (by its
specification) it will disappear when the login session ends, leading to
an Emacs daemon process that has no socket and can no longer be
connected to. Of course, unless one assumes that the daemon will not
persist the login session, but what would be the point of starting Emacs
as a daemon then?

> The 'screen' workaround does not appear to apply to Emacs, since Emacs
> is programmable and if Emacs were made setgid its users could easily
> modify Emacs's behavior to manipulate the contents of any such
> /run/emacs directory in any way they pleased.

No need for Emacs itself to be setgid, because the directory could
be created by calling an auxiliary setgid program (similar to
update-game-score).