emacsclient socket ownership

emacsclient socket ownership

[Glenn Morris]

Hi,

emacsclient defaults to predictable socket file names in /tmp:

/tmp/emacsUID/server

It checks if the socket is owned by the same user (function socket_status).
If the user is root, however, this check is ignored (master emacsclient
line 1370). Is this not a security issue? Any user can create a socket
/tmp/emacs0/server, and root emacsclient will use it.

Re: emacsclient socket ownership

[Stefan Monnier]

> It checks if the socket is owned by the same user (function socket_status).
> If the user is root, however, this check is ignored (master emacsclient
> line 1370). Is this not a security issue? Any user can create a socket
> /tmp/emacs0/server, and root emacsclient will use it.

Sounds like a security issue, yes: root may end up talking to some other
user's Emacs.  This seems to date back to

    commit 9f637eea618b3b6b764b92405a480c254756f94a
    Author: Gerd Moellmann <gerd@gnu.org>
    Date:   Fri Jan 28 15:02:20 2000 +0000

        (socket_status): New function.
        (main): if $LOGNAME or $USER exist and differ from our euid, look
        for a socket based on the UID associated with the name.

so it's likely meant for the case where you `su` (or `sudo`) and want to
use emacsclient from root but connect to your main (non-root) Emacs server.

Not sure how to reconcile the two.  I guess the risk is reduced in
practice for the following reason: server.el should hopefully signal an
error if it can't create&own /tmp/emacsUID/server, so emacsclient only
risks connecting to a wrong Emacs if:
- you forgot to start your Emacs server.
- your Emacs failed to start and you didn't notice it.
- server.el did not check things carefully enough and the attacker
  managed to replace your socket with his (e.g. /tmp/emacsUID/ or /tmp is
  somehow writable for the attacker).


        Stefan

Re: emacsclient socket ownership

[Yuri Khan]

On Fri, Nov 2, 2018 at 10:39 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > It checks if the socket is owned by the same user (function socket_status).
> > If the user is root, however, this check is ignored (master emacsclient
> > line 1370). Is this not a security issue? Any user can create a socket
> > /tmp/emacs0/server, and root emacsclient will use it.
>
> Sounds like a security issue, yes: root may end up talking to some other
> user's Emacs.

Talking, in and of itself, is not a vulnerability. Can the limited
user’s server.el actually entice the root’s emacsclient to do
something that user would not be able to do?

Re: emacsclient socket ownership

[Stefan Monnier]

> Talking, in and of itself, is not a vulnerability. Can the limited
> user’s server.el actually entice the root’s emacsclient to do
> something that user would not be able to do?

Right, the problem is not really that the other end of the socket
belongs to another user, but that the other end may be something else
than intended (e.g. it could be some unsuspecting daemon running as
root: the attacker just made the root user send "garbage" to that
daemon which may lead to exploiting a vulnerability in the daemon).

I agree that the problem may not be the most threatening there is if you
consider random attackers trying to exploit vulnerabilities anywhere
they can, but if you consider an attacker aiming at a particular user
and able to adjust its attack based on knowledge of the user's usage
pattern, I'm sure we can come up with scenarios where this problem can
be exploited.


        Stefan

Re: emacsclient socket ownership

[Paul Eggert]

On 11/2/18 11:49 AM, Stefan Monnier wrote:
> I'm sure we can come up with scenarios where this problem can
> be exploited.

Yes, me too. Let's close the hole. The (minor) convenience here is not 
worth the security vulnerability.

Re: emacsclient socket ownership

[Stefan Monnier]

>> I'm sure we can come up with scenarios where this problem can
>> be exploited.
> Yes, me too.  Let's close the hole.

Not sure how, tho: as mentioned, just checking that the socket is owned
by root might not be sufficient (the attacker may have just put
a symlink to some other socket that belongs to root but that really
doesn't expect the kind of data emacsclient sends).


        Stefan

Re: emacsclient socket ownership

[Paul Eggert]

On 11/2/18 1:30 PM, Stefan Monnier wrote:
> the attacker may have just put
> a symlink to some other socket that belongs to root but that really
> doesn't expect the kind of data emacsclient sends

We could refuse to follow symlinks, no? If that's not enough there are 
more drastic things to try.

Re: emacsclient socket ownership

[Glenn Morris]

Thanks for looking at this. (I wish you'd reply-to-all though...)

Stefan Monnier wrote:

> so it's likely meant for the case where you `su` (or `sudo`) and want to
> use emacsclient from root but connect to your main (non-root) Emacs server.

Tramp methods would seem a better alternative for this.
So I suggest favoring (slight) security over (slighter) convenience, and
eliminating the emacsclient UID 0 exception.

> I guess the risk is reduced in practice for the following reason:
> server.el should hopefully signal an error if it can't create&own
> /tmp/emacsUID/server, so emacsclient only risks connecting to a wrong
> Emacs if:
> - you forgot to start your Emacs server.
> - your Emacs failed to start and you didn't notice it.
> - server.el did not check things carefully enough and the attacker
>   managed to replace your socket with his (e.g. /tmp/emacsUID/ or /tmp is
>   somehow writable for the attacker).

If you are in the habit of using emasclient -a "", none of the server.el
checks apply. emacsclient will simply start talking to the running
server if it finds one. /tmp is usually world writable.

> Right, the problem is not really that the other end of the socket
> belongs to another user, but that the other end may be something else
> than intended (e.g. it could be some unsuspecting daemon running as root

That's beyond what I was thinking about initially, and would also apply
to non-root users. I was thinking of the case where non-root Emacs eg
runs a keylogger to watch what root types.


BTW is /tmp still the right default location for these sockets, or
should it be eg /run or XDG_RUNTIME_DIR these days?

Re: emacsclient socket ownership

[Stefan Monnier]

>> so it's likely meant for the case where you `su` (or `sudo`) and want to
>> use emacsclient from root but connect to your main (non-root) Emacs server.
> Tramp methods would seem a better alternative for this.

I think they cover fairly different use-cases.   E.g. this emacsclient
trick is used when root sets his $EDITOR to emacsclient and AFAIK Tramp
isn't an option in that case.

> BTW is /tmp still the right default location for these sockets, or
> should it be eg /run or XDG_RUNTIME_DIR these days?

Good question.  /run is not an option for non-root users, I believe.

Re: emacsclient socket ownership

[Paul Eggert]

Glenn Morris wrote:
> BTW is /tmp still the right default location for these sockets, or
> should it be eg /run or XDG_RUNTIME_DIR these days?

XDG_RUNTIME_DIR indeed sounds like it would be better nowadays.

Re: emacsclient socket ownership

[Paul Eggert]

Stefan Monnier wrote:
> /run is not an option for non-root users, I believe.

It works for me on Ubuntu 18.04.1 and seems to be used for this sort of thing:

$ ls -ld $XDG_RUNTIME_DIR
drwx------ 11 eggert eggert 260 Nov  4 23:21 /run/user/1000
$ mkdir $XDG_RUNTIME_DIR/emacs
$ ls -l $XDG_RUNTIME_DIR
total 0
srw-rw-rw-  1 eggert eggert   0 Nov  4 08:32 bus
drwx------  3 eggert eggert  60 Nov  4 08:32 dbus-1
drwx------  2 eggert eggert  60 Nov  4 23:18 dconf
drwxr-xr-x  2 eggert eggert  40 Nov  4 23:21 emacs
drwx--x--x  2 eggert eggert  60 Nov  4 08:32 gdm
drwx------  3 eggert eggert  60 Nov  4 08:32 gnome-shell
drwx------  2 eggert eggert 140 Nov  4 08:32 gnupg
dr-x------  2 eggert eggert   0 Nov  4 08:32 gvfs
drwx------  2 eggert eggert 120 Nov  4 08:43 keyring
drwx------  2 eggert eggert  80 Nov  4 08:32 pulse
drwxr-xr-x  2 eggert eggert  80 Nov  4 08:32 systemd
-rw-------  1 eggert eggert   0 Nov  4 08:33 update-notifier.pid

Re: emacsclient socket ownership

[Daniel Pittman]

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

On Mon, Nov 5, 2018 at 2:27 AM Paul Eggert <eggert@cs.ucla.edu> wrote:

> Stefan Monnier wrote:
> > /run is not an option for non-root users, I believe.
>
> It works for me on Ubuntu 18.04.1 and seems to be used for this sort of
> thing:


There is no /run on macOS, and I'm pretty sure at least OpenBSD have
rejected the idea.

Would not a better choice be to locate the socket at
${HOME}/.emacs.d/${something} instead?  That avoids the need to make it
globally accessible in the first place.

I'd also note that root can bypass file permissions, and it isn't exactly a
complex protocol to implement ... but also that root can simply change
userid to the appropriate value at will, and access it, should they wish.

At heart, I don't think this is really a security issue, so much as that
root is the ultimate force for bypassing all protection in the Unix world.
Without going to something akin to SELinux, or some similar MAC
system,  there isn't any way to prevent root accessing any socket, by
design.

So, the very best case would be that emacsclient makes this check as a
convenience to prevent surprises to the user, and would not materially
improve the security of the system against users with root permissions.

[-- Attachment #2: Type: text/html, Size: 1591 bytes --]

Re: emacsclient socket ownership

[Stefan Monnier]

> There is no /run on macOS, and I'm pretty sure at least OpenBSD have
> rejected the idea.

It's OK: we can use OS-specific filenames.

And we'd want to preserve compatibility between old emacsclient and new
server.el and vice versa.

> Would not a better choice be to locate the socket at
> ${HOME}/.emacs.d/${something} instead?

That's another option, indeed.
IIRC it tends to work poorly when $HOME is on a network file system.

> At heart, I don't think this is really a security issue, so much as that
> root is the ultimate force for bypassing all protection in the Unix world.
> Without going to something akin to SELinux, or some similar MAC
> system,  there isn't any way to prevent root accessing any socket, by
> design.

The problem is not Emacs trying to prevent root's emacsclient from
connecting, but root's emacsclient trying to avoid connecting
inadvertently to an attacker's socket.


        Stefan

Re: emacsclient socket ownership

[Paul Eggert]

On 11/6/18 9:19 AM, Daniel Pittman wrote:
> On Mon, Nov 5, 2018 at 2:27 AM Paul Eggert <eggert@cs.ucla.edu 
> <mailto:eggert@cs.ucla.edu>> wrote:
>
>     Stefan Monnier wrote:
>     > /run is not an option for non-root users, I believe.
>
>     It works for me on Ubuntu 18.04.1 and seems to be used for this
>     sort of thing:
>
>
> There is no /run on macOS, and I'm pretty sure at least OpenBSD have 
> rejected the idea.

That's OK. Emacs can use /run if available, and fall back on the current 
approach (with /tmp) otherwise.

>
> Would not a better choice be to locate the socket at 
> ${HOME}/.emacs.d/${something} instead?  That avoids the need to make 
> it globally accessible in the first place.

/run is better because it does not survive reboot, and avoids security 
and availability issues on networked filesystems.


> there isn't any way to prevent root accessing any socket, by design.

Of course, but that's not the issue. The concern here is whether a 
non-root user can trick a root program into doing stuff that root 
doesn't really want to do.

Re: emacsclient socket ownership

[Glenn Morris]

Since discussion seems to have stalled I have gone ahead and removed the
root exception (in master; I think it should be in emacs-26). I have
opened bugs 33366 and 33367 for related topics that were mentioned, I
suggest any future followups go there.

Re: emacsclient socket ownership

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 13 Nov 2018 13:21:48 -0500
> Cc: Daniel Pittman <slippycheeze@google.com>, monnier@iro.umontreal.ca,
> 	emacs-devel@gnu.org
> 
> 
> Since discussion seems to have stalled I have gone ahead and removed the
> root exception (in master; I think it should be in emacs-26).

No, please don't make this change on the release branch.

Re: emacsclient socket ownership

[Michael Heerdegen]

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

> XDG_RUNTIME_DIR indeed sounds like it would be better nowadays.

What has got installed seems to prevent me to start a server from an
Emacs started with gksu unless I change server-socket-dir in .emacs of
that user:

  signal(file-error ("Creating directory" "Permission denied"
   "/run/user/1000/emacs"))
  files--ensure-directory("/run/user/1000/emacs")
  make-directory("/run/user/1000/emacs" t)
  server-ensure-safe-dir("/run/user/1000/emacs")
  server-start(nil inhibit-prompt)

Internet searching seems to indicate that XDG_RUNTIME_DIR is not always
set by such tools.  Is XDG_RUNTIME_DIR really a good choice?


Thanks,

Michael

Re: emacsclient socket ownership

[Glenn Morris]

Michael Heerdegen wrote:

> What has got installed seems to prevent me to start a server from an
> Emacs started with gksu unless I change server-socket-dir in .emacs of
> that user:
>
>   signal(file-error ("Creating directory" "Permission denied"
>    "/run/user/1000/emacs"))
>   files--ensure-directory("/run/user/1000/emacs")
>   make-directory("/run/user/1000/emacs" t)
>   server-ensure-safe-dir("/run/user/1000/emacs")
>   server-start(nil inhibit-prompt)
>
> Internet searching seems to indicate that XDG_RUNTIME_DIR is not always
> set by such tools. 

Maybe you need to use gksu -l, though you might then have X auth issues.

> Is XDG_RUNTIME_DIR really a good choice?

It is the right directory to use for these things, yes.

Running a modern graphical application as another user is a complicated
business. I wouldn't do it personally.

Re: emacsclient socket ownership

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 05 Dec 2018 14:38:19 -0500
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Stefan Monnier <monnier@iro.umontreal.ca>,
> 	emacs-devel@gnu.org
> 
> > Is XDG_RUNTIME_DIR really a good choice?
> 
> It is the right directory to use for these things, yes.

Maybe we should have a defcustom for those who don't want
XDG_RUNTIME_DIR to be used, even if it exists.  Or maybe we should
check it for being writable before using it, and otherwise fall back
on TMPDIR, as before.

Re: emacsclient socket ownership

[Glenn Morris]

Eli Zaretskii wrote:

> Maybe we should have a defcustom for those who don't want
> XDG_RUNTIME_DIR to be used, even if it exists.

emacsclient can't know about defcustoms.

> Or maybe we should check it for being writable before using it, and
> otherwise fall back on TMPDIR, as before.

I don't think Emacs should work around user environments that are bogus
in this way.

Re: emacsclient socket ownership

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: michael_heerdegen@web.de,  eggert@cs.ucla.edu,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 05 Dec 2018 15:02:24 -0500
> 
> Eli Zaretskii wrote:
> 
> > Maybe we should have a defcustom for those who don't want
> > XDG_RUNTIME_DIR to be used, even if it exists.
> 
> emacsclient can't know about defcustoms.

emacsclient could have a command-line option for that.

> > Or maybe we should check it for being writable before using it, and
> > otherwise fall back on TMPDIR, as before.
> 
> I don't think Emacs should work around user environments that are bogus
> in this way.

It's for letting users get back pre-27 behavior.  They could want it
for any number of reasons.

Re: emacsclient socket ownership

[Glenn Morris]

PS this is the same (non-Emacs) issue as https://debbugs.gnu.org/32413 .
You would have the same issue with dbus-related features of Emacs.

See also https://bugs.debian.org/766464 etc.

Re: emacsclient socket ownership

[Michael Heerdegen]

Glenn Morris <rgm@gnu.org> writes:

> Maybe you need to use gksu -l, though you might then have X auth
> issues.

If you mean that emacs then doesn't start - yes, I have this little
issue then.

> Running a modern graphical application as another user is a
> complicated business. I wouldn't do it personally.

Well, I used to start another separate xsession for other users, but
that already stopped working some time ago.  Thanks to the switch to
systemd or something like this, when I finish one session, the other X
session immediately crashes.

I guess I only have some years left to work with my computer in a
reasonable way...not the fault of Emacs, of cause.


Michael.

Re: emacsclient socket ownership

[Paul Eggert]

On 12/5/18 12:19 PM, Eli Zaretskii wrote:
> emacsclient could have a command-line option for that.

emacsclient already has the '-s SOCKET' option. Plus, you can set 
XDG_RUNTIME_DIR (or unset it) in the environment before invoking 
emacsclient. As far as I can see, this should let users avoid the 
problems Michael describes. (And if I'm wrong, what further emacsclient 
option would be useful?)

> It's for letting users get back pre-27 behavior.  They could want it
> for any number of reasons.
Unsetting XDG_RUNTIME_DIR should get the pre-27 behavior in emacsclient.

PS. One really should know what one is doing to be playing with this 
stuff (due to security reasons), and unless I'm missing something the 
people who know what they're doing should be able to get the behavior 
they want by using the knobs that are already in master.

Re: emacsclient socket ownership

[Paul Eggert]

gksu has been removed from Debian and other GNU/Linux distributions for 
maintenance and security reasons (see 
<https://jeremy.bicha.net/2018/03/21/gksu-is-dead/>), so I'd rather 
focus on any other tools having similar problems. That being said, you 
should be able to work around the gksu issue by setting (or unsetting) 
XDG_RUNTIME_DIR in gksu's subsidiary environment before invoking Emacs 
(not that I recommend using gksu at all...).

Re: emacsclient socket ownership

[Eli Zaretskii]

> Cc: michael_heerdegen@web.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 5 Dec 2018 16:36:59 -0800
> 
> On 12/5/18 12:19 PM, Eli Zaretskii wrote:
> > emacsclient could have a command-line option for that.
> 
> emacsclient already has the '-s SOCKET' option. Plus, you can set 
> XDG_RUNTIME_DIR (or unset it) in the environment before invoking 
> emacsclient. As far as I can see, this should let users avoid the 
> problems Michael describes. (And if I'm wrong, what further emacsclient 
> option would be useful?)
> 
> > It's for letting users get back pre-27 behavior.  They could want it
> > for any number of reasons.
> Unsetting XDG_RUNTIME_DIR should get the pre-27 behavior in emacsclient.

How about mentioning these in NEWS, then?  Maybe in the manual as
well?

Re: emacsclient socket ownership

[Paul Eggert]

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

On 12/5/18 10:37 PM, Eli Zaretskii wrote:
> How about mentioning these in NEWS, then?  Maybe in the manual as
> well?

Sure I installed the attached.


[-- Attachment #2: 0001-Mention-unsetting-XDG_RUNTIME_DIR-in-doc.patch --]
[-- Type: text/x-patch, Size: 1662 bytes --]

From 2f613d37554660ca7119d4b0a6d5553b55807102 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 6 Dec 2018 11:07:18 -0800
Subject: [PATCH] Mention unsetting XDG_RUNTIME_DIR in doc.

---
 doc/misc/efaq.texi | 5 ++++-
 etc/NEWS           | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/doc/misc/efaq.texi b/doc/misc/efaq.texi
index d457267c24..19770455f1 100644
--- a/doc/misc/efaq.texi
+++ b/doc/misc/efaq.texi
@@ -2009,7 +2009,10 @@ Using an already running Emacs process
 @file{server} in a well-known directory, typically
 @file{$XDG_RUNTIME_DIR/emacs} if Emacs is running under an X Window System
 desktop and @file{$TMPDIR/emacs@var{userid}} otherwise.  See the variable
-@code{server-socket-dir}.
+@code{server-socket-dir}.  Traditionally, Emacs used
+@file{$TMPDIR/emacs@var{userid}} even when running under an X desktop;
+if you prefer this traditional (and less-secure) behavior, unset
+@env{XDG_RUNTIME_DIR} before invoking Emacs and @samp{emacsclient}.
 
 To get your news reader, mail reader, etc., to invoke
 @samp{emacsclient}, try setting the environment variable @code{EDITOR}
diff --git a/etc/NEWS b/etc/NEWS
index 60cba9ed46..e7f2d606f8 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -133,6 +133,8 @@ to apply.
 as the directory for client/server sockets, if Emacs is running
 under an X Window System desktop that sets the XDG_RUNTIME_DIR
 environment variable to indicate where session sockets should go.
+To get the old and less-secure behavior, unset XDG_RUNTIME_DIR before
+invoking emacs and emacsclient.
 
 ---
 *** When run by root, emacsclient no longer connects to non-root sockets.
-- 
2.19.2

Re: emacsclient socket ownership

[Eli Zaretskii]

> Cc: rgm@gnu.org, michael_heerdegen@web.de, monnier@iro.umontreal.ca,
>  emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 6 Dec 2018 11:08:33 -0800
> 
> On 12/5/18 10:37 PM, Eli Zaretskii wrote:
> > How about mentioning these in NEWS, then?  Maybe in the manual as
> > well?
> 
> Sure I installed the attached.

Thanks.

Re: emacsclient socket ownership

[Glenn Morris]

Paul Eggert wrote:

> Subject: [PATCH] Mention unsetting XDG_RUNTIME_DIR in doc.

XDG_RUNTIME_DIR isn't specific to Emacs, so the Emacs docs should not
suggest unsetting it, because this will affect external processes that
Emacs spawns. It would be better to refer to EMACS_SOCKET_NAME.

Re: emacsclient socket ownership

[Paul Eggert]

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

On 12/6/18 12:26 PM, Glenn Morris wrote:
> It would be better to refer to EMACS_SOCKET_NAME.

Sure, that's easy. I installed the attached.


[-- Attachment #2: 0001-Mention-EMACS_SOCKET_NAME-not-XDG_RUNTIME_DIR.patch --]
[-- Type: text/x-patch, Size: 1995 bytes --]

From 0e8e5da1e8da0752fc02bf590a17697af4c0afd3 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 6 Dec 2018 12:59:42 -0800
Subject: [PATCH] Mention EMACS_SOCKET_NAME, not XDG_RUNTIME_DIR.

---
 doc/misc/efaq.texi | 8 ++++++--
 etc/NEWS           | 4 ++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/doc/misc/efaq.texi b/doc/misc/efaq.texi
index 19770455f1..18a857f7dc 100644
--- a/doc/misc/efaq.texi
+++ b/doc/misc/efaq.texi
@@ -2011,8 +2011,12 @@ Using an already running Emacs process
 desktop and @file{$TMPDIR/emacs@var{userid}} otherwise.  See the variable
 @code{server-socket-dir}.  Traditionally, Emacs used
 @file{$TMPDIR/emacs@var{userid}} even when running under an X desktop;
-if you prefer this traditional (and less-secure) behavior, unset
-@env{XDG_RUNTIME_DIR} before invoking Emacs and @samp{emacsclient}.
+if you prefer this traditional (and less-secure) behavior, you
+can set the environment variable @env{EMACS_SOCKET_NAME} to
+@samp{$TMPDIR/emacs@var{userid}/server} before invoking Emacs and
+@samp{emacsclient}, although it will be your responsibility to create
+the directory @samp{$TMPDIR/emacs@var{userid}} with appropriate
+ownership and permissions.
 
 To get your news reader, mail reader, etc., to invoke
 @samp{emacsclient}, try setting the environment variable @code{EDITOR}
diff --git a/etc/NEWS b/etc/NEWS
index e7f2d606f8..cad44f9233 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -133,8 +133,8 @@ to apply.
 as the directory for client/server sockets, if Emacs is running
 under an X Window System desktop that sets the XDG_RUNTIME_DIR
 environment variable to indicate where session sockets should go.
-To get the old and less-secure behavior, unset XDG_RUNTIME_DIR before
-invoking emacs and emacsclient.
+To get the old, less-secure behavior, you can set the
+EMACS_SOCKET_NAME environment variable to an appropriate value.
 
 ---
 *** When run by root, emacsclient no longer connects to non-root sockets.
-- 
2.19.2