bug#35300: 27.0.50; emacsclient on remote sessions no longer works

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Óscar Fuentes]

After initiating my KDE desktop session on the local machine, I also
execute emacs --daemon.

On the local machine `emacsclient -c'.

Now, if I ssh into my machine, `emacsclient -c -nw' shows:

emacsclient: can't find socket; have you started the server?
emacsclient: To start the server in Emacs, type "M-x server-start".
emacsclient: No socket or alternate editor.  Please use:

        --socket-name
        --server-file      (or environment variable EMACS_SERVER_FILE)
        --alternate-editor (or environment variable ALTERNATE_EDITOR)

I looked into NEWS and it has a few lines describing some changes but it
is not more useful than the above text about what I need to do to get a
working emacsclient.

(Saying "To get the old, less-secure behavior, you can set the
EMACS_SOCKET_NAME environment variable to an appropriate value." is not
helpful at all, it assumes that the user knows things that previously he
wasn't required to know.)


In GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit)
 of 2019-04-14 built on sky
Repository revision: 4fb1a06413224424bc7d022192c2434232dc5e9c
Repository branch: fill_column_indicator
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: Debian GNU/Linux buster/sid

Configured using:
 'configure --without-toolkit-scroll-bars --with-x-toolkit=lucid
 --with-modules'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GSETTINGS GLIB NOTIFY INOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB LUCID X11 XDBE XIM
MODULES THREADS PDUMPER GMP

Important settings:
  value of $LANG: C
  locale-coding-system: nil

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Glenn Morris]

Works for me. I guess your ssh is not setting XDG_RUNTIME_DIR.
This is handled by pam_systemd, ref eg
https://www.freedesktop.org/software/systemd/man/pam_systemd.html

See discussion in https://debbugs.gnu.org/33847

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Óscar Fuentes]

retitle Improve emacsclient error message to inform about new requirements
stop

Glenn Morris <rgm@gnu.org> writes:

> Works for me. I guess your ssh is not setting XDG_RUNTIME_DIR.
> This is handled by pam_systemd, ref eg
> https://www.freedesktop.org/software/systemd/man/pam_systemd.html

I have

UsePAM no

in my sshd config. Thanks Glenn.

> See discussion in https://debbugs.gnu.org/33847

Before reporting this issue I found and skimmed over that one. What a
mess.

My main concern about this is to ensure that any change that breaks
functionality goes with prominent notes about the change and how to
adapt to it. Showing just the standard error message in the output of
emacsclient when it knows the probable origin of the problem is not user
friendly. We must give a proper note about the existence of new modes of
failure and explain (or at least hint) how to deal with them.

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 19 Apr 2019 03:54:29 +0200
> Cc: 35300@debbugs.gnu.org
> 
> My main concern about this is to ensure that any change that breaks
> functionality goes with prominent notes about the change and how to
> adapt to it. Showing just the standard error message in the output of
> emacsclient when it knows the probable origin of the problem is not user
> friendly. We must give a proper note about the existence of new modes of
> failure and explain (or at least hint) how to deal with them.

Feel free to suggest a more useful text, including for NEWS.

Thanks.

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Feel free to suggest a more useful text, including for NEWS.

Since I reported this bug because I was stuck and just now barely
attained the required knowledge to fix it on my specific case, I'm far
from being the best qualified person to document anything.

FWIW, the least emacsclient could do is to inform about its dependency
on XDG_RUNTIME_DIR when it fails to connect to the server and that
variable is undefined.

Anyways, bug#33847 should be settled first. I sympathize with the
reporter there and hope a better method can be achieved.

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: rgm@gnu.org,  35300@debbugs.gnu.org
> Date: Fri, 19 Apr 2019 14:36:27 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Feel free to suggest a more useful text, including for NEWS.
> 
> Since I reported this bug because I was stuck and just now barely
> attained the required knowledge to fix it on my specific case, I'm far
> from being the best qualified person to document anything.

I actually think you are very qualified, because you know what is
missing from the current text.

It would be useful if you could at least point out what information
should be added to the current text to make it more useful to your use
case.  Someone else could then convert that to an actual patch.

Thanks.

> FWIW, the least emacsclient could do is to inform about its dependency
> on XDG_RUNTIME_DIR when it fails to connect to the server and that
> variable is undefined.

Any other missing pieces of information you'd like to be added?

Also, I don't think I understand clearly what exactly failed in your
case.  Did you have XDG_RUNTIME_DIR defined or didn't you?  If you
did, what exactly caused the failure to find the socket?

Thanks.

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> FWIW, the least emacsclient could do is to inform about its dependency
>> on XDG_RUNTIME_DIR when it fails to connect to the server and that
>> variable is undefined.
>
> Any other missing pieces of information you'd like to be added?

All the documentation I browsed for an hour before figuring out what the
problem was? :-)

> Also, I don't think I understand clearly what exactly failed in your
> case.  Did you have XDG_RUNTIME_DIR defined or didn't you?  If you
> did, what exactly caused the failure to find the socket?

Some time ago I disabled PAM on my sshd_config, because it was not use
for me and it adds complexity to the log-in procedure. Everything worked
fine for years, emacsclient included, until just a few days ago that I
started using Emacs 27 for testing one of the new features.

Really, if XDG_RUNTIME_DIR stays, I volunteer to implement the change I
proposed to emacsclient. But I hope something better is found.

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: rgm@gnu.org,  35300@debbugs.gnu.org
> Date: Fri, 19 Apr 2019 15:31:10 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> FWIW, the least emacsclient could do is to inform about its dependency
> >> on XDG_RUNTIME_DIR when it fails to connect to the server and that
> >> variable is undefined.
> >
> > Any other missing pieces of information you'd like to be added?
> 
> All the documentation I browsed for an hour before figuring out what the
> problem was? :-)

Thanks, but that's not specific enough for me to take any practical
action.

> > Also, I don't think I understand clearly what exactly failed in your
> > case.  Did you have XDG_RUNTIME_DIR defined or didn't you?  If you
> > did, what exactly caused the failure to find the socket?
> 
> Some time ago I disabled PAM on my sshd_config, because it was not use
> for me and it adds complexity to the log-in procedure. Everything worked
> fine for years, emacsclient included, until just a few days ago that I
> started using Emacs 27 for testing one of the new features.

So you didn't have XDG_RUNTIME_DIR set?  In that case, I feel I
understand the issue even less, because when XDG_RUNTIME_DIR is not
defined, emacsclient is supposed to fall back to the old behavior...

(If my questions bother you, feel free to tell, and I will stop.)

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Any other missing pieces of information you'd like to be added?
>> 
>> All the documentation I browsed for an hour before figuring out what the
>> problem was? :-)
>
> Thanks, but that's not specific enough for me to take any practical
> action.

As I said before, I don't have the knowledge to be helpful here, except
for what applies to my specific case, and even then it is the bare
minimum.

>> > Also, I don't think I understand clearly what exactly failed in your
>> > case.  Did you have XDG_RUNTIME_DIR defined or didn't you?  If you
>> > did, what exactly caused the failure to find the socket?
>> 
>> Some time ago I disabled PAM on my sshd_config, because it was not use
>> for me and it adds complexity to the log-in procedure. Everything worked
>> fine for years, emacsclient included, until just a few days ago that I
>> started using Emacs 27 for testing one of the new features.
>
> So you didn't have XDG_RUNTIME_DIR set?  In that case, I feel I
> understand the issue even less, because when XDG_RUNTIME_DIR is not
> defined, emacsclient is supposed to fall back to the old behavior...

IIUC, the Emacs server creates the local socket under the directory
pointed by XDG_RUNTIME_DIR. When emacsclient starts, if XDG_RUNTIME_DIR
is not set it simply does not know where to find the socket.

IIRC from the other bug report pointed by Glenn, it seems that there is
a fallback behavior, but it only works if the system is configured for
that.

> (If my questions bother you, feel free to tell, and I will stop.)

Not at all, I'm glad to help you as much as I can.

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: rgm@gnu.org,  35300@debbugs.gnu.org
> Date: Fri, 19 Apr 2019 16:30:39 +0200
> 
> >> Some time ago I disabled PAM on my sshd_config, because it was not use
> >> for me and it adds complexity to the log-in procedure. Everything worked
> >> fine for years, emacsclient included, until just a few days ago that I
> >> started using Emacs 27 for testing one of the new features.
> >
> > So you didn't have XDG_RUNTIME_DIR set?  In that case, I feel I
> > understand the issue even less, because when XDG_RUNTIME_DIR is not
> > defined, emacsclient is supposed to fall back to the old behavior...
> 
> IIUC, the Emacs server creates the local socket under the directory
> pointed by XDG_RUNTIME_DIR. When emacsclient starts, if XDG_RUNTIME_DIR
> is not set it simply does not know where to find the socket.

So you are saying that XDG_RUNTIME_DIR did exist when the server was
started, but ceased to exist by the time emacsclient was started?

> > (If my questions bother you, feel free to tell, and I will stop.)
> 
> Not at all, I'm glad to help you as much as I can.

Thanks.

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > So you didn't have XDG_RUNTIME_DIR set?  In that case, I feel I
>> > understand the issue even less, because when XDG_RUNTIME_DIR is not
>> > defined, emacsclient is supposed to fall back to the old behavior...
>> 
>> IIUC, the Emacs server creates the local socket under the directory
>> pointed by XDG_RUNTIME_DIR. When emacsclient starts, if XDG_RUNTIME_DIR
>> is not set it simply does not know where to find the socket.
>
> So you are saying that XDG_RUNTIME_DIR did exist when the server was
> started,

Yes.

> but ceased to exist by the time emacsclient was started?

It didn't cease to exist. That variable is automatically set when you
log in and certain components are installed and enabled.

I ssh-ed to the machine and no XDG_RUNTIME_DIR was set on that session
because the machinery that sets it up when you log in through ssh was
disabled.

That is: at the time there was two sessions, one local with
XDG_RUNTIME_DIR set and from where the Emacs server was started and a
remote session with no XDG_RUNTIME_DIR and, therefore, with emacsclient
unable to connect to the Emacs server unless you tell it where the local
socket is.

As explained on the bug report referenced by Glenn, there are other
scenarios where XDG_RUNTIME_DIR is not set (in that case, when the Emacs
server starts as a service.)

You can read more about XDG_RUNTIME_DIR here:

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Glenn Morris]

Eli Zaretskii wrote:

> Feel free to suggest a more useful text, including for NEWS.

    *** emacsclient supports an EMACS_SOCKET_NAME environment variable.
    If set, it provides the default server socket filename.
    The command-line emacsclient option --socket-name overrides it.

    *** The Emacs server/client now use $XDG_RUNTIME_DIR/emacs for sockets,
    if the XDG_RUNTIME_DIR environment variable is defined.
    This is more secure than the old practice of using TMPDIR.
    If your client cannot find the server socket, check XDG_RUNTIME_DIR
    has the same value in both client and server environments.
    You can use the EMACS_SOCKET_NAME environment variable (see above)
    to specify a particular socket.

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Óscar Fuentes]

Glenn Morris <rgm@gnu.org> writes:

>     *** emacsclient supports an EMACS_SOCKET_NAME environment variable.
>     If set, it provides the default server socket filename.
>     The command-line emacsclient option --socket-name overrides it.
>
>     *** The Emacs server/client now use $XDG_RUNTIME_DIR/emacs for sockets,
>     if the XDG_RUNTIME_DIR environment variable is defined.
>     This is more secure than the old practice of using TMPDIR.
>     If your client cannot find the server socket, check XDG_RUNTIME_DIR
>     has the same value in both client and server environments.
>     You can use the EMACS_SOCKET_NAME environment variable (see above)
>     to specify a particular socket.

This is an improvement, yes. But I'll like to see even a stronger hint
on the output of emacsclient, once we agree that there is no better
solution than to use XDG_RUNTIME_DIR.

It is unfortunate that this change added more requirements to
emacsclient to work correctly.

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

I installed into master the attached patch, which should cause emacsclient to 
output something like the following in your situation:

emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment?
emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.)

I hope this helps.

[-- Attachment #2: 0001-Improve-XDG_RUNTIME_DIR-diagnostic.patch --]
[-- Type: text/x-patch, Size: 2369 bytes --]

From b3a12c62c9085171866256f00dada4326a4a3084 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 20 Apr 2019 09:31:47 -0700
Subject: [PATCH] Improve XDG_RUNTIME_DIR diagnostic

* lib-src/emacsclient.c (set_local_socket):
If there appears to be an XDG runtime directory for the user
but XDG_RUNTIME_DIR is unset, suggest setting it while warning
about potential security issues (Bug#35300).
---
 lib-src/emacsclient.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
index f476840898..5871a18ce6 100644
--- a/lib-src/emacsclient.c
+++ b/lib-src/emacsclient.c
@@ -1357,6 +1357,7 @@ set_local_socket (char const *server_name)
   int tmpdirlen = -1;
   int socknamelen = -1;
   uid_t uid = geteuid ();
+  bool tmpdir_used = false;
 
   if (strchr (server_name, '/')
       || (ISSLASH ('\\') && strchr (server_name, '\\')))
@@ -1389,6 +1390,7 @@ set_local_socket (char const *server_name)
 	    }
 	  socknamelen = local_sockname (sockname, socknamesize, tmpdirlen,
 					uid, server_name);
+	  tmpdir_used = true;
 	}
     }
 
@@ -1462,11 +1464,27 @@ set_local_socket (char const *server_name)
   if (sock_status < 0)
     message (true, "%s: Invalid socket owner\n", progname);
   else if (sock_status == ENOENT)
-    message (true,
-	     ("%s: can't find socket; have you started the server?\n"
-	      "%s: To start the server in Emacs,"
-	      " type \"M-x server-start\".\n"),
-	     progname, progname);
+    {
+      if (tmpdir_used)
+	{
+	  uintmax_t id = uid;
+	  char sockdirname[socknamesize];
+	  int sockdirnamelen = snprintf (sockdirname, sizeof sockdirname,
+					 "/run/user/%"PRIuMAX, id);
+	  if (0 <= sockdirnamelen && sockdirnamelen < sizeof sockdirname
+	      && euidaccess (sockdirname, X_OK) == 0)
+	    message
+	      (true,
+	       ("%s: Should XDG_RUNTIME_DIR='%s' be in the environment?\n"
+		"%s: (Be careful: XDG_RUNTIME_DIR is security-related.)\n"),
+	       progname, sockdirname, progname);
+	}
+      message (true,
+	       ("%s: can't find socket; have you started the server?\n"
+		"%s: To start the server in Emacs,"
+		" type \"M-x server-start\".\n"),
+	       progname, progname);
+    }
   else
     message (true, "%s: can't stat %s: %s\n",
 	     progname, sockname, strerror (sock_status));
-- 
2.17.1

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Óscar Fuentes]

Paul Eggert <eggert@cs.ucla.edu> writes:

> I installed into master the attached patch, which should cause
> emacsclient to output something like the following in your situation:
>
> emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment?
> emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.)
>
> I hope this helps.

I have the same reservations expressed by Glenn in emacs-devel, but this
would help me in the wrong way when emacsclient failed on me.

Seeing the message, I'll try this quick hack:

$ XDG_RUNTIME_DIR='/run/user/1000' emacsclient

and that probably would makes things "work".

A more educative message would be something like:

"The environment variable XDG_RUNTIME_DIR is not set and, since version
27, Emacs depends on it to communicate with the server. Usually this
variable is automatically set by the system at log-in. Check any
configuration that might affect how the environment is build when a user
logs-in."

bug#35300: 27.0.50; emacsclient on remote sessions no longer works

[Glenn Morris]

My version of a friendly emacsclient failure message would be:

emacsclient: can't find a socket.
Tried: /run/user/1000/emacs/X, /tmp/emacs/1000/X, whatever
Things to check:
Is a server running?  To start one, use "M-x server-start" in Emacs.
Do the client and server see the same values for XDG_RUNTIME_DIR, TMPDIR?
Current values: A, B