emacsclient startup messages

emacsclient startup messages

[Pedro Andres Aranda Gutierrez]

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

Hi

I was used to the
emacsclient: can't find socket; have you started the server?
emacsclient: To start the server in Emacs, type "M-x server-start".
messages and, despite finding them somehow annoying, well I could live with
them :-)

Lately, this has grown to
emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment?
emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.)
emacsclient: can't find socket; have you started the server?
emacsclient: To start the server in Emacs, type "M-x server-start".
in my Linux system and, well, it starts being too much...

even with a emacsclient -q there is no way to silence
emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment?
emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.)

If I say quiet, I mean quiet and that should include this message... more
so if they ask me maybe do something that maybe I shouldn't because it is
security related...

Isn't there any other way of saying this in a more positive way so that I
either decide to take action or not? Could'nt we also silence this warning
in -q?

Just thinking...
/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

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

Re: emacsclient startup messages

[Eli Zaretskii]

> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Tue, 26 Oct 2021 07:26:35 +0200
> 
> I was used to the 
> emacsclient: can't find socket; have you started the server?
> emacsclient: To start the server in Emacs, type "M-x server-start".
> messages and, despite finding them somehow annoying, well I could live with them :-)
> 
> Lately, this has grown to
> emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment?
> emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.)
> emacsclient: can't find socket; have you started the server?
> emacsclient: To start the server in Emacs, type "M-x server-start".
> in my Linux system and, well, it starts being too much...
> 
> even with a emacsclient -q there is no way to silence
> emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment?
> emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.)
> 
> If I say quiet, I mean quiet and that should include this message... more so if they ask me maybe do
> something that maybe I shouldn't because it is security related... 

That's not what -q is meant to do.  From the --help display:

  -q, --quiet        Don't display messages on success

IOW, it isn't supposed to suppress warning, only verbose messages
about _successful_ actions.

> Isn't there any other way of saying this in a more positive way so that I either decide to take action or not?
> Could'nt we also silence this warning in -q?

How about redirecting stderr to /dev/null?

Re: emacsclient startup messages

[Jim Porter]

On 10/25/2021 10:26 PM, Pedro Andres Aranda Gutierrez wrote:
> even with a emacsclient -q there is no way to silence
> emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment?
> emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.)
> 
> If I say quiet, I mean quiet and that should include this message... 
> more so if they ask me maybe do something that maybe I shouldn't because 
> it is security related...

I believe this is bug#51327. From how I understand it, this is fallout 
from the fix for bug#33847 that occurs when `emacsclient' is run and 
can't find a daemon to connect to. As far as I can tell, it's an 
indicator of a real bug: the code is checking TMPDIR for the socket even 
on a system with XDG_RUNTIME_DIR set (and ultimately, the to-be-created 
daemon will put its socket in XDG_RUNTIME_DIR).

- Jim

Re: emacsclient startup messages

[Pedro Andres Aranda Gutierrez]

Redirecting to stderr is a nice work-around ;-)

/PA

Enviado desde mi iPad

El 26 oct 2021, a las 14:18, Eli Zaretskii <eliz@gnu.org> escribió:

>> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
>> Date: Tue, 26 Oct 2021 07:26:35 +0200
>> 
>> I was used to the 
>> emacsclient: can't find socket; have you started the server?
>> emacsclient: To start the server in Emacs, type "M-x server-start".
>> messages and, despite finding them somehow annoying, well I could live with them :-)
>> 
>> Lately, this has grown to
>> emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment?
>> emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.)
>> emacsclient: can't find socket; have you started the server?
>> emacsclient: To start the server in Emacs, type "M-x server-start".
>> in my Linux system and, well, it starts being too much...
>> 
>> even with a emacsclient -q there is no way to silence
>> emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment?
>> emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.)
>> 
>> If I say quiet, I mean quiet and that should include this message... more so if they ask me maybe do
>> something that maybe I shouldn't because it is security related... 
> 
> That's not what -q is meant to do.  From the --help display:
> 
>  -q, --quiet        Don't display messages on success
> 
> IOW, it isn't supposed to suppress warning, only verbose messages
> about _successful_ actions.
> 
>> Isn't there any other way of saying this in a more positive way so that I either decide to take action or not?
>> Could'nt we also silence this warning in -q?
> 
> How about redirecting stderr to /dev/null?

Re: emacsclient startup messages

[Pedro Andres Aranda Gutierrez]

At least it is confusing when you cannot silence this with --quiet when you can silence the start-emacs-server message independently of the bug, which does also exist.

/PA

Enviado desde mi iPad

> El 26 oct 2021, a las 18:32, Jim Porter <jporterbugs@gmail.com> escribió:
> 
>> On 10/25/2021 10:26 PM, Pedro Andres Aranda Gutierrez wrote:
>> even with a emacsclient -q there is no way to silence
>> emacsclient: Should XDG_RUNTIME_DIR='/run/user/1000' be in the environment?
>> emacsclient: (Be careful: XDG_RUNTIME_DIR is security-related.)
>> If I say quiet, I mean quiet and that should include this message... more so if they ask me maybe do something that maybe I shouldn't because it is security related...
> 
> I believe this is bug#51327. From how I understand it, this is fallout from the fix for bug#33847 that occurs when `emacsclient' is run and can't find a daemon to connect to. As far as I can tell, it's an indicator of a real bug: the code is checking TMPDIR for the socket even on a system with XDG_RUNTIME_DIR set (and ultimately, the to-be-created daemon will put its socket in XDG_RUNTIME_DIR).
> 
> - Jim

Re: emacsclient startup messages

[Jim Porter]

On 10/26/2021 9:46 AM, Pedro Andres Aranda Gutierrez wrote:
> At least it is confusing when you cannot silence this with --quiet when you can silence the start-emacs-server message independently of the bug, which does also exist.

For me, this is a great example of something I'm *glad* wasn't silenced 
with --quiet. If it had been, I might have missed it and wouldn't have 
realized there's an actual bug here (at least, I think there's a bug; 
the code is a bit tricky).

- Jim

Re: emacsclient startup messages

[Pedro Andres Aranda Gutierrez]

Good point too:-)

Enviado desde mi iPhone

> El 26 oct 2021, a las 19:03, Jim Porter <jporterbugs@gmail.com> escribió:
> 
> On 10/26/2021 9:46 AM, Pedro Andres Aranda Gutierrez wrote:
>> At least it is confusing when you cannot silence this with --quiet when you can silence the start-emacs-server message independently of the bug, which does also exist.
> 
> For me, this is a great example of something I'm *glad* wasn't silenced with --quiet. If it had been, I might have missed it and wouldn't have realized there's an actual bug here (at least, I think there's a bug; the code is a bit tricky).
> 
> - Jim

Re: emacsclient startup messages

[Ulrich Mueller]

>>>>> On Tue, 26 Oct 2021, Jim Porter wrote:

> I believe this is bug#51327. From how I understand it, this is fallout
> from the fix for bug#33847 that occurs when `emacsclient' is run and 
> can't find a daemon to connect to. As far as I can tell, it's an
> indicator of a real bug: the code is checking TMPDIR for the socket
> even on a system with XDG_RUNTIME_DIR set (and ultimately, the
> to-be-created daemon will put its socket in XDG_RUNTIME_DIR).

There can be situations where there is an XDG environment for the client
but not for the daemon.

Especially, XDG_RUNTIME_DIR is specific to the login session, so if you
want the daemon to persist across different login sessions, you may want
to create the socket elsewhere.

Re: emacsclient startup messages

[Jim Porter]

On 10/30/2021 10:39 AM, Ulrich Mueller wrote:
>>>>>> On Tue, 26 Oct 2021, Jim Porter wrote:
> 
>> I believe this is bug#51327. From how I understand it, this is fallout
>> from the fix for bug#33847 that occurs when `emacsclient' is run and
>> can't find a daemon to connect to. As far as I can tell, it's an
>> indicator of a real bug: the code is checking TMPDIR for the socket
>> even on a system with XDG_RUNTIME_DIR set (and ultimately, the
>> to-be-created daemon will put its socket in XDG_RUNTIME_DIR).
> 
> There can be situations where there is an XDG environment for the client
> but not for the daemon.

Right, the patch in bug#33847 should handle that case correctly, but I'm 
pretty sure the current implementation opens users who spawn the Emacs 
daemon on-demand to symlink attacks. That's due to the code needing to 
check both XDG_RUNTIME_DIR and TMPDIR before being sure there's no 
daemon to connect to.

I can think of two ways to avoid this issue:

1) Have a flag that lets users explicitly state whether emacsclient can 
fall back to looking in TMPDIR. Then, if the flag is unset, emacsclient 
will only look in XDG_RUNTIME_DIR; if it is set, it will look in 
XDG_RUNTIME_DIR first, and fall back to TMPDIR if necessary. However, 
this means that either your case in bug#33847 or the "daemon on demand" 
case will need to explicitly set this flag, which is annoying.

2) If XDG_RUNTIME_DIR and ALTERNATE_EDITOR/--alternate-editor are both 
set, never check TMPDIR. This should let both cases work without 
requiring users to explicitly set a flag anywhere, but it the lack of 
explicitness could be more confusing. I think this should work fine in 
all cases, since users running `emacs --daemon' without XDG probably 
won't be using ALTERNATE_EDITOR (the daemon should always be running, so 
there's no need for an alternate editor).

- Jim

Re: emacsclient startup messages

[Jim Porter]

On 10/30/2021 12:16 PM, Jim Porter wrote:
> On 10/30/2021 10:39 AM, Ulrich Mueller wrote:
>> There can be situations where there is an XDG environment for the client
>> but not for the daemon.
> 
> Right, the patch in bug#33847 should handle that case correctly, but I'm 
> pretty sure the current implementation opens users who spawn the Emacs 
> daemon on-demand to symlink attacks. That's due to the code needing to 
> check both XDG_RUNTIME_DIR and TMPDIR before being sure there's no 
> daemon to connect to.
> 
> I can think of two ways to avoid this issue:
[snip]
> 2) If XDG_RUNTIME_DIR and ALTERNATE_EDITOR/--alternate-editor are both 
> set, never check TMPDIR. This should let both cases work without 
> requiring users to explicitly set a flag anywhere, but it the lack of 
> explicitness could be more confusing. I think this should work fine in 
> all cases, since users running `emacs --daemon' without XDG probably 
> won't be using ALTERNATE_EDITOR (the daemon should always be running, so 
> there's no need for an alternate editor).

I posted a patch for method (2) to bug#51327 here: 
<https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02638.html>.

Re: emacsclient startup messages

[Pedro Andres Aranda Gutierrez]

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

HI Jim,
I've patched my emacs-28 source and am compiling the whole beat right now.
Once installed, I'll let you know :-)
/PA

On Sat, 30 Oct 2021 at 21:47, Jim Porter <jporterbugs@gmail.com> wrote:

> On 10/30/2021 12:16 PM, Jim Porter wrote:
> > On 10/30/2021 10:39 AM, Ulrich Mueller wrote:
> >> There can be situations where there is an XDG environment for the client
> >> but not for the daemon.
> >
> > Right, the patch in bug#33847 should handle that case correctly, but I'm
> > pretty sure the current implementation opens users who spawn the Emacs
> > daemon on-demand to symlink attacks. That's due to the code needing to
> > check both XDG_RUNTIME_DIR and TMPDIR before being sure there's no
> > daemon to connect to.
> >
> > I can think of two ways to avoid this issue:
> [snip]
> > 2) If XDG_RUNTIME_DIR and ALTERNATE_EDITOR/--alternate-editor are both
> > set, never check TMPDIR. This should let both cases work without
> > requiring users to explicitly set a flag anywhere, but it the lack of
> > explicitness could be more confusing. I think this should work fine in
> > all cases, since users running `emacs --daemon' without XDG probably
> > won't be using ALTERNATE_EDITOR (the daemon should always be running, so
> > there's no need for an alternate editor).
>
> I posted a patch for method (2) to bug#51327 here:
> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02638.html>.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

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

Re: emacsclient startup messages

[Pedro Andres Aranda Gutierrez]

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

Hi again,
it took a bit longer, but here we are... The patch does what I was dreaming
of (i.e. getting rid of the xdg message when calling emacsclient with -a or
when $ALTERNATE_EDITOR is set.

Thanks!
/PA

On Sun, 31 Oct 2021 at 11:03, Pedro Andres Aranda Gutierrez <
paaguti@gmail.com> wrote:

> HI Jim,
> I've patched my emacs-28 source and am compiling the whole beat right now.
> Once installed, I'll let you know :-)
> /PA
>
> On Sat, 30 Oct 2021 at 21:47, Jim Porter <jporterbugs@gmail.com> wrote:
>
>> On 10/30/2021 12:16 PM, Jim Porter wrote:
>> > On 10/30/2021 10:39 AM, Ulrich Mueller wrote:
>> >> There can be situations where there is an XDG environment for the
>> client
>> >> but not for the daemon.
>> >
>> > Right, the patch in bug#33847 should handle that case correctly, but
>> I'm
>> > pretty sure the current implementation opens users who spawn the Emacs
>> > daemon on-demand to symlink attacks. That's due to the code needing to
>> > check both XDG_RUNTIME_DIR and TMPDIR before being sure there's no
>> > daemon to connect to.
>> >
>> > I can think of two ways to avoid this issue:
>> [snip]
>> > 2) If XDG_RUNTIME_DIR and ALTERNATE_EDITOR/--alternate-editor are both
>> > set, never check TMPDIR. This should let both cases work without
>> > requiring users to explicitly set a flag anywhere, but it the lack of
>> > explicitness could be more confusing. I think this should work fine in
>> > all cases, since users running `emacs --daemon' without XDG probably
>> > won't be using ALTERNATE_EDITOR (the daemon should always be running,
>> so
>> > there's no need for an alternate editor).
>>
>> I posted a patch for method (2) to bug#51327 here:
>> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02638.html>.
>>
>
>
> --
> Fragen sind nicht da um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

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

Re: emacsclient startup messages

[Pedro Andres Aranda Gutierrez]

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

Hi Eli,

I have been applying the patch to my Ubuntu 20.04 builds for a couple of
days and everything as worked well. Wouldn't it be a good time to put it
into emacs-28?

Just asking, /PA

On Sun, 31 Oct 2021 at 16:44, Pedro Andres Aranda Gutierrez <
paaguti@gmail.com> wrote:

> Hi again,
> it took a bit longer, but here we are... The patch does what I was
> dreaming of (i.e. getting rid of the xdg message when calling emacsclient
> with -a or when $ALTERNATE_EDITOR is set.
>
> Thanks!
> /PA
>
> On Sun, 31 Oct 2021 at 11:03, Pedro Andres Aranda Gutierrez <
> paaguti@gmail.com> wrote:
>
>> HI Jim,
>> I've patched my emacs-28 source and am compiling the whole beat right now.
>> Once installed, I'll let you know :-)
>> /PA
>>
>> On Sat, 30 Oct 2021 at 21:47, Jim Porter <jporterbugs@gmail.com> wrote:
>>
>>> On 10/30/2021 12:16 PM, Jim Porter wrote:
>>> > On 10/30/2021 10:39 AM, Ulrich Mueller wrote:
>>> >> There can be situations where there is an XDG environment for the
>>> client
>>> >> but not for the daemon.
>>> >
>>> > Right, the patch in bug#33847 should handle that case correctly, but
>>> I'm
>>> > pretty sure the current implementation opens users who spawn the Emacs
>>> > daemon on-demand to symlink attacks. That's due to the code needing to
>>> > check both XDG_RUNTIME_DIR and TMPDIR before being sure there's no
>>> > daemon to connect to.
>>> >
>>> > I can think of two ways to avoid this issue:
>>> [snip]
>>> > 2) If XDG_RUNTIME_DIR and ALTERNATE_EDITOR/--alternate-editor are both
>>> > set, never check TMPDIR. This should let both cases work without
>>> > requiring users to explicitly set a flag anywhere, but it the lack of
>>> > explicitness could be more confusing. I think this should work fine in
>>> > all cases, since users running `emacs --daemon' without XDG probably
>>> > won't be using ALTERNATE_EDITOR (the daemon should always be running,
>>> so
>>> > there's no need for an alternate editor).
>>>
>>> I posted a patch for method (2) to bug#51327 here:
>>> <https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02638.html
>>> >.
>>>
>>
>>
>> --
>> Fragen sind nicht da um beantwortet zu werden,
>> Fragen sind da um gestellt zu werden
>> Georg Kreisler
>>
>
>
> --
> Fragen sind nicht da um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

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

Re: emacsclient startup messages

[Eli Zaretskii]

> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Fri, 5 Nov 2021 08:04:28 +0100
> Cc: Ulrich Mueller <ulm@gentoo.org>, emacs-devel <emacs-devel@gnu.org>, 
> 	Jim Porter <jporterbugs@gmail.com>
> 
> Hi Eli,
> 
> I have been applying the patch to my Ubuntu 20.04 builds for a couple of days and everything as worked
> well. Wouldn't it be a good time to put it into emacs-28?

Not yet.

Ulrich, any comments on this?  Including its importance for Emacs 28?

Re: emacsclient startup messages

[Ulrich Mueller]

>>>>> On Fri, 05 Nov 2021, Eli Zaretskii wrote:

>> I have been applying the patch to my Ubuntu 20.04 builds for a couple
>> of days and everything as worked well. Wouldn't it be a good time to
>> put it into emacs-28?

> Not yet.

> Ulrich, any comments on this?  Including its importance for Emacs 28?

I've just tested with current master.

The patch breaks the workflow used with Gentoo's app-emacs/emacs-daemon
package. That is, a persistent Emacs daemon started with its socket in
${TMPDIR}/emacs${UID}/server, and emacsclient started with XDG_*
variables in its environment:

   $ emacsclient -t --alternate-editor=
   emacsclient: can't find socket; have you started the server?
   emacsclient: To start the server in Emacs, type "M-x server-start".
   Another Emacs daemon is already running at process id 6084
   Error: server did not start correctly
   Error: Could not start the Emacs daemon
   $ 

I haven't looked into the details of the code yet, but shouldn't the
client first try to connect to an existing socket at both possible
locations? And only start a new daemon when both attempts have failed?

Re: emacsclient startup messages

[Jim Porter]

On 11/5/2021 2:40 AM, Ulrich Mueller wrote:
>>>>>> On Fri, 05 Nov 2021, Eli Zaretskii wrote:
> 
>>> I have been applying the patch to my Ubuntu 20.04 builds for a couple
>>> of days and everything as worked well. Wouldn't it be a good time to
>>> put it into emacs-28?
> 
>> Not yet.
> 
>> Ulrich, any comments on this?  Including its importance for Emacs 28?
> 
> I've just tested with current master.
> 
> The patch breaks the workflow used with Gentoo's app-emacs/emacs-daemon
> package. That is, a persistent Emacs daemon started with its socket in
> ${TMPDIR}/emacs${UID}/server, and emacsclient started with XDG_*
> variables in its environment:
> 
>     $ emacsclient -t --alternate-editor=
>     emacsclient: can't find socket; have you started the server?
>     emacsclient: To start the server in Emacs, type "M-x server-start".
>     Another Emacs daemon is already running at process id 6084
>     Error: server did not start correctly
>     Error: Could not start the Emacs daemon
>     $

Why are you (or the Gentoo package) running with `--alternate-editor=' 
if a daemon was already started? If it's feasible to stop doing that, it 
would be very helpful. The compromise that I suggested was that if the 
alternate editor is unset, emacsclient will try both XDG_RUNTIME_DIR and 
TMPDIR, so this use-case should work with the patch, provided you can 
remove `--alternate-editor='.

> I haven't looked into the details of the code yet, but shouldn't the
> client first try to connect to an existing socket at both possible
> locations? And only start a new daemon when both attempts have failed?

No, this behavior opens users to symlink attacks if they call 
emacsclient without an Emacs daemon already running, which is why Emacs 
uses XDG_RUNTIME_DIR in the first place. Even the compromise in my patch 
isn't truly ideal: a user might normally run `emacs --daemon' on startup 
(with XDG_RUNTIME_DIR already set) and then call emacsclient *without* 
setting the alternate editor; if the daemon had been killed somehow, 
emacsclient will currently check TMPDIR, opening the user to a symlink 
attack.

I'm not 100% clear on how dangerous the symlink attack is, but if Emacs 
is going to try and prevent it, I think it should at least ensure that 
it's easy for users to set things up so that they're not vulnerable.

Strictly from a security perspective, Emacs 27 is better here: if 
XDG_RUNTIME_DIR is set when you call emacsclient, Emacs 27 will *only* 
look in the XDG_RUNTIME_DIR for a socket, not in TMPDIR. Thus, users 
with XDG_RUNTIME_DIR are never vulnerable. However, for the Gentoo case 
above, that requires unsetting XDG_RUNTIME_DIR before calling 
emacsclient. Doing it this way maintains Emacs' security against symlink 
attacks, since a user has to explicitly opt into looking in TMPDIR for a 
socket.

My compromise patch is the best I could come up with for a solution that 
a) protects users who run `emacs --daemon' on-demand via the "alternate 
editor" setting and b) allows the Gentoo case to work without having to 
unset XDG_RUNTIME_DIR. As mentioned, there's still a vulnerability here, 
but the patch should shrink the number of users who hit the vuln.

As for my personal opinion on this, I think it would be best to revert 
bug#33847 (which supports the Gentoo use-case). If necessary, we could 
provide a way to explicitly opt into the (insecure) bug#33847 behavior, 
e.g. by adding a --fall-back-to-tmpdir-sockets flag. I'm also ok with my 
compromise patch, even though it's not perfect.

I think something should be done here for Emacs 28, but given how close 
it is to release, I'm not sure what's the safest move. Hopefully the 
above explains the pros and cons of our options fairly clearly.

- Jim

Re: emacsclient startup messages

[Ulrich Mueller]

>>>>> On Fri, 05 Nov 2021, Jim Porter wrote:

> On 11/5/2021 2:40 AM, Ulrich Mueller wrote:
>> $ emacsclient -t --alternate-editor=
>> emacsclient: can't find socket; have you started the server?
>> emacsclient: To start the server in Emacs, type "M-x server-start".
>> Another Emacs daemon is already running at process id 6084
>> Error: server did not start correctly
>> Error: Could not start the Emacs daemon
>> $

> Why are you (or the Gentoo package) running with `--alternate-editor='
> if a daemon was already started?

Because the user may not be sure if a daemon is running, and may want to
start it just in case? Which fails with the patch applied.

Note that the Gentoo package only starts the daemon, calling emacsclient
is up to the user. I'm not keen to receive bug reports because users'
workflows are being broken. (In fact, broken again, as we already had a
round of that with Emacs 27).

> [...]

> As for my personal opinion on this, I think it would be best to revert
> bug#33847 (which supports the Gentoo use-case). If necessary, we could
> provide a way to explicitly opt into the (insecure) bug#33847
> behavior, e.g. by adding a --fall-back-to-tmpdir-sockets flag. I'm
> also ok with my compromise patch, even though it's not perfect.

Not helpful. :(

The main problem with XDG_RUNTIME_DIR ist that it doesn't persist
between login sessions:

| 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.
|
| https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

In contrast to that, an Emacs running as a daemon can survive logout,
and the user may want to reconnect to it later. This is impossible if
the socket is located in XDG_RUNTIME_DIR, which is scrapped upon logout.

In bug #33847 I had suggested to create the socket in ${HOME}/emacs.d/
instead. Unfortunately this was shot down, with the arguments summarised
in <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33847#100>:

| This would be worse for several reasons: you'd need to disambiguate
| via hostname, you'd need to guarantee hostnames are unique, you'd have
| problems when NFS is flaky or hanging in your home directory, and
| you'd need to deal with socket files that survive OS crashes.

I still don't think that any of these arguments is substantive:

- Unix sockets use the file system just as a namespace, which is unique
  on any given host. The socket itself is local; there is no sharing
  across hosts. Therefore I believe that creating a single socket would
  be enough.

- Flaky NFS shouldn't be a problem, because once the communication is
  established, the filesystem is no longer involved in it. (Of course,
  there may be NFS problems at the time of startup, but then again,
  Emacs cannot read the user's local config either.)

- A stale socket will just use a single inode, and can be reused the
  next time the server is started.

Re: emacsclient startup messages

[Pedro Andres Aranda Gutierrez]

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

I remember the controversy with emacs as daemon, emacsclients and
friends...

hmmm... from a user's perspective I really don't know what I gain by having
emacs running as a daemon if I boot up my laptop to say watch a film or
listen to a recording from my satellite PVR just for the fun of it.

Maybe this sounds like a very old user or a very old and very bad habit
(mea maxima culpa) but when I want to edit, I write emacs or emacslient on
my CLI or click on the emacs icon or drag-and-drop a file on the emacs icon
and then emacs stays alive as long as I want it to stay alive. Because,
yes, I do watch films and that is somehow not very compatible with writing
(code or whatever). Or am I too monotask? ;-)

Best, /PA

On Fri, 5 Nov 2021 at 18:52, Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Fri, 05 Nov 2021, Jim Porter wrote:
>
> > On 11/5/2021 2:40 AM, Ulrich Mueller wrote:
> >> $ emacsclient -t --alternate-editor=
> >> emacsclient: can't find socket; have you started the server?
> >> emacsclient: To start the server in Emacs, type "M-x server-start".
> >> Another Emacs daemon is already running at process id 6084
> >> Error: server did not start correctly
> >> Error: Could not start the Emacs daemon
> >> $
>
> > Why are you (or the Gentoo package) running with `--alternate-editor='
> > if a daemon was already started?
>
> Because the user may not be sure if a daemon is running, and may want to
> start it just in case? Which fails with the patch applied.
>
> Note that the Gentoo package only starts the daemon, calling emacsclient
> is up to the user. I'm not keen to receive bug reports because users'
> workflows are being broken. (In fact, broken again, as we already had a
> round of that with Emacs 27).
>
> > [...]
>
> > As for my personal opinion on this, I think it would be best to revert
> > bug#33847 (which supports the Gentoo use-case). If necessary, we could
> > provide a way to explicitly opt into the (insecure) bug#33847
> > behavior, e.g. by adding a --fall-back-to-tmpdir-sockets flag. I'm
> > also ok with my compromise patch, even though it's not perfect.
>
> Not helpful. :(
>
> The main problem with XDG_RUNTIME_DIR ist that it doesn't persist
> between login sessions:
>
> | 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.
> |
> |
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
>
> In contrast to that, an Emacs running as a daemon can survive logout,
> and the user may want to reconnect to it later. This is impossible if
> the socket is located in XDG_RUNTIME_DIR, which is scrapped upon logout.
>
> In bug #33847 I had suggested to create the socket in ${HOME}/emacs.d/
> instead. Unfortunately this was shot down, with the arguments summarised
> in <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33847#100>:
>
> | This would be worse for several reasons: you'd need to disambiguate
> | via hostname, you'd need to guarantee hostnames are unique, you'd have
> | problems when NFS is flaky or hanging in your home directory, and
> | you'd need to deal with socket files that survive OS crashes.
>
> I still don't think that any of these arguments is substantive:
>
> - Unix sockets use the file system just as a namespace, which is unique
>   on any given host. The socket itself is local; there is no sharing
>   across hosts. Therefore I believe that creating a single socket would
>   be enough.
>
> - Flaky NFS shouldn't be a problem, because once the communication is
>   established, the filesystem is no longer involved in it. (Of course,
>   there may be NFS problems at the time of startup, but then again,
>   Emacs cannot read the user's local config either.)
>
> - A stale socket will just use a single inode, and can be reused the
>   next time the server is started.
>


-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

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

Re: emacsclient startup messages

[Jim Porter]

On 11/6/2021 4:35 AM, Pedro Andres Aranda Gutierrez wrote:
> hmmm... from a user's perspective I really don't know what I gain by 
> having emacs running as a daemon if I boot up my laptop to say watch a 
> film or listen to a recording from my satellite PVR just for the fun of it.

This is roughly in line with how I use Emacs too: I start it up, I edit 
stuff, and then when I'm done (which may take anywhere from a few 
minutes to a few weeks), I close Emacs entirely.

However, for the issue of these startup messages, I think the main thing 
we need to do here is to figure out whether the XDG_RUNTIME_DIR warning 
is a legitimate warning (i.e. it's informing the user that they're 
vulnerable to a symlink attack), and then either a) fix the 
vulnerability or b) remove the warning if there's no vuln.

I'm not an expert on this sort of security analysis, so I can't really 
say for sure whether this is a real vulnerability. However, Paul 
Eggert's message[1] agrees it *is* insecure, so it should be fixed 
(somehow). The question then would be how to close the vulnerability 
while supporting the behavior that Gentoo would like (see Ulrich's 
messages).

- Jim

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg02641.html

Re: emacsclient startup messages

[Peter Oliver]

On Fri, 5 Nov 2021, Ulrich Mueller wrote:

>>>>>> On Fri, 05 Nov 2021, Jim Porter wrote:
>
>> On 11/5/2021 2:40 AM, Ulrich Mueller wrote:
>>> $ emacsclient -t --alternate-editor=
>>> emacsclient: can't find socket; have you started the server?
>>> emacsclient: To start the server in Emacs, type "M-x server-start".
>>> Another Emacs daemon is already running at process id 6084
>>> Error: server did not start correctly
>>> Error: Could not start the Emacs daemon
>>> $
>
>> Why are you (or the Gentoo package) running with `--alternate-editor='
>> if a daemon was already started?
>
> Because the user may not be sure if a daemon is running, and may want to
> start it just in case? Which fails with the patch applied.

Thinking out loud, would systemd socket activation help here, or would that simply move the issue elsewhere?

https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html#index-socket-activation_002c-systemd_002c-Emacs

-- 
Peter Oliver