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

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
The master branch was recently updated to place the server socket in
XDG_RUNTIME_DIR, with a fallback to the previous TMPDIR location.
This will make emacsclient fail when the server has been started from
an environment where XDG_RUNTIME_DIR is not set.

For example, if emacs --daemon is started on a Gentoo system via
OpenRC's start-stop-daemon, then emacs will create the socket in
${TMPDIR}/emacs${UID}/, but emacsclient (in the user's X session)
will search for it in ${XDG_RUNTIME_DIR}/emacs/:

$ emacsclient -c
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)

(The reason is of course that start-stop-daemon does not set the XDG_*
variables. However, I don't see how it could do that in any reasonable
way. Presumably it would have to happen via PAM and ConsoleKit, but the
latter doesn't have a display at that point.)

Suggested solutions:
- Create the socket in a dir that is more readily available, for example
  somewhere under ${HOME}/emacs.d/, or
- Have emacsclient fall back to TMPDIR as well when no socket is found
  under XDG_RUNTIME_DIR.



Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
The specification of XDG_RUNTIME_DIR at
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
says this:

| $XDG_RUNTIME_DIR defines the base directory relative to which
| user-specific non-essential runtime files and other file objects
| (such as sockets, named pipes, ...) should be stored. [...]

| The lifetime of the directory MUST be bound to the user being logged
| in. It MUST be created when the user first logs in and if the user
| fully logs out the directory MUST be removed. [...]
| Files in the directory MUST not survive reboot or a full
| logout/login cycle.

It explicitly says that the directory does not persist between login
sessions, whereas - at least in my understanding - an Emacs running as
a daemon is supposed to survive logout, so that the user can reconnect
to it later. (For example, I use that feature for persistent ERC
sessions.)

So, I would conclude that XDG_RUNTIME_DIR is not an appropriate
location for the socket of a daemon process.



Reply | Threaded
Open this post in threaded view
|

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

Paul Eggert
In reply to this post by Ulrich Mueller-2
> Suggested solutions:
> - Create the socket in a dir that is more readily available, for example
>   somewhere under ${HOME}/emacs.d/

Unfortunately that won't work well in general, as $HOME/emacs.d might not exist,
or it might be on a network file system where a host-specific file would be
inappropriate.

> - Have emacsclient fall back to TMPDIR as well when no socket is found
>   under XDG_RUNTIME_DIR

This would run afoul of the security issues that led to the use of
XDG_RUNTIME_DIR in the first place.

Instead, I suggest unsetting XDG_RUNTIME_DIR if you wish to start an Emacs
client or server that is independent of your session and are on a host that is
secured well enough so that the security issues are of no concern.
Alternatively, you can use --socket-name when starting emacsclient.



Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
>>>>> On Tue, 25 Dec 2018, Paul Eggert wrote:

> Instead, I suggest unsetting XDG_RUNTIME_DIR if you wish to start an
> Emacs client or server that is independent of your session and are on
> a host that is secured well enough so that the security issues are of
> no concern. Alternatively, you can use --socket-name when starting
> emacsclient.

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?

Also, 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.



Reply | Threaded
Open this post in threaded view
|

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

Paul Eggert
Ulrich Mueller 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. The default should be
secure, though.

> 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.

Tools like 'screen' that predate XDG_RUNTIME_DIR traditionally suffered from
similar security problems. On my Fedora 29 platform, 'screen' works around the
problem by being setgid 'screen' and putting files under /run/screen/S-eggert,
where /run/screen is mode drwxrwxr-x with owner 'root' and group 'screen'. The
exact location of the /run/screen directory is platform-specific; I guess that
it typically used to be /tmp/screens but got moved due to security concerns.

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.



Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
>>>>> 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).



Reply | Threaded
Open this post in threaded view
|

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

Paul Eggert
Ulrich Mueller wrote:
> IMHO, unsetting a standard variable like XDG_RUNTIME_DIR (as you've
> suggested above) in the user's session isn't really an option.

You're right, unsetting it for an entire session would mean that you want all
programs (not just Emacs) to not use XDG_RUNTIME_DIR, and that sounds too
drastic. I don't recall suggesting that.

> And a
> wrapper script around emacsclient would be just awkward.

It's not *that* awkward, and it may be acceptable if the situation you describe
is unusual enough.

> 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.

Although I'm not a big fan of environment variables, it might make sense for
server.el to look at EMACS_SOCKET_NAME, for consistency with emacsclient.

> 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?

There's no mechanism in Emacs to do that now. It would be OK to add one, I expect.

> If it is a security issue, then why isn't the fix in the emacs-26 branch
> as well?

emacs-26 at this point is meant for fixing regressions, and the problem in
question is not a regression. Anyway, this change was too risky for the emacs-26
branch.

> Also, why is there still a fallback to TMPDIR, if that's
> considered insecure?

On a system that doesn't set XDG_RUNTIME_DIR it was the best we could easily do.
If we can come up with something better for those systems, that would be good.

For systems with XDG_RUNTIME_DIR it would probably be better to not reinvent
this particular wheel. That is, for users who prefer Emacs to run only when they
are logged in, XDG_RUNTIME_DIR seems to be the way to go. For users who prefer
Emacs to always be running, even when they are not logged in, we should use some
other mechanism.

> XDG_RUNTIME_DIR is simply not suitable for the purpose, because (by its
> specification) it will disappear when the login session ends,

I think the idea is that XDG_RUNTIME_DIR disappears when all login sessions end,
so it might survive the current session.

>> 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).

That might work, as a solution for people who want Emacs to keep running even
when they entirely log out.



Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
>>>>> On Wed, 26 Dec 2018, Paul Eggert wrote:

> Ulrich Mueller wrote:
>> XDG_RUNTIME_DIR is simply not suitable for the purpose, because (by its
>> specification) it will disappear when the login session ends,

> I think the idea is that XDG_RUNTIME_DIR disappears when all login
> sessions end, so it might survive the current session.

I still don't see why XDG_RUNTIME_DIR would be more secure than using
a directory in TMPDIR. server.el seems to take all necessary precautions
to ensure that the directory is safe:

   server-ensure-safe-dir is a compiled Lisp function in ‘server.el’.

   (server-ensure-safe-dir DIR)

   Make sure DIR is a directory with no race-condition issues.
   Creates the directory if necessary and makes sure:
   - there’s no symlink involved
   - it’s owned by us
   - it’s not readable/writable by anybody else.

In addition, emacsclient checks for the ownership of the socket before
connecting to it.

>> 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).

> That might work, as a solution for people who want Emacs to keep
> running even when they entirely log out.

It would also be rather complicated, and require creation of an emacs
group. Using a directory where the user has write access is easier.
AFAICS, the three candidates for that are TMPDIR, HOME, and
XDG_RUNTIME_DIR.

Emacs 26 uses ${TMPDIR}/emacs${UID}/ or ${HOME}/.emacs.d/server/
depending on the server-use-tcp flag. Emacs 27 will use one of these
two or ${XDG_RUNTIME_DIR} as a default (depending on the environment).
IMHO this is approaching the point where things become unpredictable
and hard to understand for the user. (And making it more customizable
won't make it simpler, I fear.)

If TMPDIR really is insecure (see above), can't the socket be placed
in ${HOME}/.emacs.d/ which is already used in the TCP case? The socket
could be named server-<system-name>, in order to avoid issues with NFS
mounted directories.



Reply | Threaded
Open this post in threaded view
|

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

Paul Eggert
Ulrich Mueller wrote:

> server.el seems to take all necessary precautions
> to ensure that the directory is safe:

>     (server-ensure-safe-dir DIR)
>
>     Make sure DIR is a directory with no race-condition issues.
>     Creates the directory if necessary and makes sure:
>     - there’s no symlink involved
>     - it’s owned by us
>     - it’s not readable/writable by anybody else.

The problem on the server side isn't in server-ensure-safe-dir, it's that
something could happen between the time that server-ensure-safe-dir checks that
DIR is safe, and the time that DIR is actually used.

> In addition, emacsclient checks for the ownership of the socket before
> connecting to it.

Sure, but that doesn't mean it's the right socket. We discussed this last month;
please see the thread containing:

https://lists.gnu.org/archive/html/emacs-devel/2018-11/msg00051.html

>>> 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).
>
>> That might work, as a solution for people who want Emacs to keep
>> running even when they entirely log out.
>
> It would also be rather complicated, and require creation of an emacs
> group.

True. I also would prefer a better solution than that.

> Emacs 26 uses ${TMPDIR}/emacs${UID}/ or ${HOME}/.emacs.d/server/
> depending on the server-use-tcp flag. Emacs 27 will use one of these
> two or ${XDG_RUNTIME_DIR} as a default (depending on the environment).
> IMHO this is approaching the point where things become unpredictable
> and hard to understand for the user. (And making it more customizable
> won't make it simpler, I fear.)

True, it has gotten more complicated. If we could simplify it without reopening
the security holes that would be a good thing.

> can't the socket be placed
> in ${HOME}/.emacs.d/ which is already used in the TCP case? The socket
> could be named server-<system-name>, in order to avoid issues with NFS
> mounted directories.

That would cause problems when Emacs crashes or the system reboots, since the
directory wouldn't be cleaned up automatically. So although we could add this as
an option, I'm a bit leery of making it the default.



Reply | Threaded
Open this post in threaded view
|

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

Richard Stallman
In reply to this post by Paul Eggert
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Tools like 'screen' that predate XDG_RUNTIME_DIR traditionally suffered from
  > similar security problems. On my Fedora 29 platform, 'screen' works around the
  > problem by being setgid 'screen' and putting files under /run/screen/S-eggert,
  > where /run/screen is mode drwxrwxr-x with owner 'root' and group 'screen'. The
  > exact location of the /run/screen directory is platform-specific; I guess that
  > it typically used to be /tmp/screens but got moved due to security concerns.

Is it possible to arrange for each user to have a directory under /run/emacs
which is owned by that user and doesn't give access to anyone else?

Maybe we could release a simple setuid program to create that directory.

--
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





Reply | Threaded
Open this post in threaded view
|

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

Paul Eggert
Richard Stallman wrote:
> Is it possible to arrange for each user to have a directory under /run/emacs
> which is owned by that user and doesn't give access to anyone else?
>
> Maybe we could release a simple setuid program to create that directory.

Although I think that would work, as Ulrich wrote in Bug#33847#26 it has an
operational problem: it requires the creation and installation of either a
setuid program (which will raise eyebrows) or the creation of a new 'emacs'
group and installation of a setgid 'emacs' program (which will raise fewer
eyebrows but is still a hassle). Adding either requirement would be a hassle for
builders and installers (e.g., how do you test the new Emacs before installing
it if you don't have rights to create a setuid program in the build directory?).
So we are looking for a better solution if possible.



Reply | Threaded
Open this post in threaded view
|

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

Paul Eggert
Ulrich, have you tried starting your Emacs server as a lingering service?
Lingering seems to be designed for the sort of thing you want to do. Look for
"enable-linger" in <https://www.freedesktop.org/software/systemd/man/loginctl.html>.



Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
>>>>> On Thu, 27 Dec 2018, Paul Eggert wrote:

> Ulrich, have you tried starting your Emacs server as a lingering
> service? Lingering seems to be designed for the sort of thing you want
> to do. Look for "enable-linger" in
> <https://www.freedesktop.org/software/systemd/man/loginctl.html>.

That would require systemd, so it is not a solution that can be
universally used. Especially it is GNU/Linux specific.



Reply | Threaded
Open this post in threaded view
|

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

Paul Eggert
Ulrich Mueller wrote:
>> Ulrich, have you tried starting your Emacs server as a lingering
>> service? Lingering seems to be designed for the sort of thing you want
>> to do. Look for "enable-linger" in
>> <https://www.freedesktop.org/software/systemd/man/loginctl.html>.
> That would require systemd, so it is not a solution that can be
> universally used. Especially it is GNU/Linux specific.

We don't need to attack the problem in general, only the problem on platforms
that have XDG_RUNTIME_DIR. What sort of platforms have XDG_RUNTIME_DIR but do
not use systemd, and how does one start a user-specific server on such platforms?



Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
In reply to this post by Paul Eggert
>>>>> On Wed, 26 Dec 2018, Paul Eggert wrote:

>> can't the socket be placed in ${HOME}/.emacs.d/ which is already used
>> in the TCP case? The socket could be named server-<system-name>, in
>> order to avoid issues with NFS mounted directories.

> That would cause problems when Emacs crashes or the system reboots,
> since the directory wouldn't be cleaned up automatically. So although
> we could add this as an option, I'm a bit leery of making it the
> default.

The only problem I see is that it would leave a stale socket file
behind, when Emacs is not properly terminated. That file would be
deleted/replaced the next time an Emacs server is started.

I guess in the typical use case we are talking about a single inode.
If the home directory is NFS mounted it may be one inode per machine.
I think that's a small price to pay, for a solution that would be both
very simple, would be available on all systems, and won't suffer from
security issues.



Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
In reply to this post by Paul Eggert
>>>>> On Fri, 28 Dec 2018, Paul Eggert wrote:

> We don't need to attack the problem in general, only the problem on
> platforms that have XDG_RUNTIME_DIR. What sort of platforms have
> XDG_RUNTIME_DIR but do not use systemd, and how does one start a
> user-specific server on such platforms?

See my original report, OpenRC and start-stop-daemon.

So you're saying that on systems that don't have XDG_RUNTIME_DIR,
placing the socket under TMPDIR is fine? Because I don't understand
that argument. If TMPDIR has security problem, then it shouldn't be
used anywhere. If it hasn't, then why can't we keep the current
(Emacs 26) solution?



Reply | Threaded
Open this post in threaded view
|

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

Paul Eggert
Ulrich Mueller wrote:
> So you're saying that on systems that don't have XDG_RUNTIME_DIR,
> placing the socket under TMPDIR is fine? Because I don't understand
> that argument. If TMPDIR has security problem, then it shouldn't be
> used anywhere. If it hasn't, then why can't we keep the current
> (Emacs 26) solution?

Because we're not absolutists. On older systems that do not have adequate
provisions for security, Emacs does the best it can: that's better than not
doing anything, and people who run older, less-secure systems are likely to not
care all that much about security anyway so this is OK. On newer systems that
are more secure, though, Emacs can be more secure.

This is not anything new. In the bad old days when /tmp wasn't sticky, Emacs was
less secure with temporary files, just like everyone else was. That didn't mean
that Emacs should never have used temporary files.



Reply | Threaded
Open this post in threaded view
|

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

Paul Eggert
In reply to this post by Ulrich Mueller-2
Ulrich Mueller wrote:
> The only problem I see is that it would leave a stale socket file
> behind, when Emacs is not properly terminated. That file would be
> deleted/replaced the next time an Emacs server is started.
>
> I guess in the typical use case we are talking about a single inode.
> If the home directory is NFS mounted it may be one inode per machine.
> I think that's a small price to pay, for a solution that would be both
> very simple, would be available on all systems, and won't suffer from
> security issues.

If we're talking NFS, we will indeed have security issues, not to mention
problems with deleting or replacing files. I can't count the number of times
I've seen messages like "NFS server not responding still trying".

The TCP case is already documented as being undesirable, and this is partly due
to security concerns. We shouldn't inflict its problems on the more-usual local
case.



Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
In reply to this post by Paul Eggert
>>>>> On Sun, 30 Dec 2018, Paul Eggert wrote:

> Because we're not absolutists. On older systems that do not have
> adequate provisions for security, Emacs does the best it can: that's
> better than not doing anything, and people who run older, less-secure
> systems are likely to not care all that much about security anyway so
> this is OK. On newer systems that are more secure, though, Emacs can
> be more secure.

Since there doesn't seem to be any progress here, please find below
the patch that I am using since some time.

From f8d87a0a89b91c120935bd5be802604b2c749767 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <[hidden email]>
Date: Sun, 20 Jan 2019 18:48:45 +0100
Subject: [PATCH] Add a fallback for the socket location in emacsclient
 (bug#33847)

* lib-src/emacsclient.c (set_local_socket): Fall back to TMPDIR
if the socket is not found under XDG_RUNTIME_DIR.
---
 lib-src/emacsclient.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
index f476840898..27b945133e 100644
--- a/lib-src/emacsclient.c
+++ b/lib-src/emacsclient.c
@@ -1356,6 +1356,7 @@ set_local_socket (char const *server_name)
   enum { socknamesize = sizeof server.un.sun_path };
   int tmpdirlen = -1;
   int socknamelen = -1;
+  int sock_status = -1;
   uid_t uid = geteuid ();
 
   if (strchr (server_name, '/')
@@ -1366,9 +1367,15 @@ set_local_socket (char const *server_name)
       /* socket_name is a file name component.  */
       char const *xdg_runtime_dir = egetenv ("XDG_RUNTIME_DIR");
       if (xdg_runtime_dir)
- socknamelen = snprintf (sockname, socknamesize, "%s/emacs/%s",
- xdg_runtime_dir, server_name);
-      else
+ {
+  socknamelen = snprintf (sockname, socknamesize, "%s/emacs/%s",
+  xdg_runtime_dir, server_name);
+  /* Check if sockname is valid and if the socket exists. */
+  if (0 <= socknamelen && socknamelen < socknamesize)
+    sock_status = socket_status (sockname, uid);
+ }
+
+      if (sock_status)
  {
   char const *tmpdir = egetenv ("TMPDIR");
   if (tmpdir)
@@ -1399,7 +1406,9 @@ set_local_socket (char const *server_name)
     }
 
   /* See if the socket exists, and if it's owned by us. */
-  int sock_status = socket_status (sockname, uid);
+  if (sock_status)
+    sock_status = socket_status (sockname, uid);
+
   if (sock_status)
     {
       /* Failing that, see if LOGNAME or USER exist and differ from
--
2.19.1




Reply | Threaded
Open this post in threaded view
|

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

Ulrich Mueller-2
>>>>> On Sun, 20 Jan 2019, Ulrich Mueller wrote:

> Since there doesn't seem to be any progress here, please find below
> the patch that I am using since some time.

Does the absence of any reply (neither here nor on emacs-devel) mean
that it is o.k. to push this?



12