bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Lars Ingebrigtsen]

Once again I find myself in the situation that I've started an Emacs at
home without an Emacs server socket, and I know there's something in a
buffer there that I want to get a hold of.  But I'm at work, and there's
no way to make Emacs start a server remotely.

It would be really nice if I could just ssh to the machine where the
Emacs is running, do "kill -USR1 <pid>" and then ... Emacs could do
something.  Like load "~/.emacs.d/load-file-USR1" or something.  Or just
start emacs-server.  

There are security implications, of course...  But does this seem like
something useful?

Writing a package that does this is easy, of course, but if you know
that this is something you need, then you'd already have started the
Emacs server anyway.  So it would have to be something that's available
in Emacs by default, because you only need it if you didn't know that
you were going to need it.  :-)


In GNU Emacs 27.0.50 (build 22, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2018-05-31 built on stories
Repository revision: c0a0351249c1e6a9307224d8337ff8916f4cf138
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description: Debian GNU/Linux 9 (stretch)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Marcin Borkowski]

On 2018-06-04, at 13:29, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Once again I find myself in the situation that I've started an Emacs at
> home without an Emacs server socket, and I know there's something in a
> buffer there that I want to get a hold of.  But I'm at work, and there's
> no way to make Emacs start a server remotely.
>
> It would be really nice if I could just ssh to the machine where the
> Emacs is running, do "kill -USR1 <pid>" and then ... Emacs could do
> something.  Like load "~/.emacs.d/load-file-USR1" or something.  Or just
> start emacs-server.
>
> There are security implications, of course...  But does this seem like
> something useful?
>
> Writing a package that does this is easy, of course, but if you know
> that this is something you need, then you'd already have started the
> Emacs server anyway.  So it would have to be something that's available
> in Emacs by default, because you only need it if you didn't know that
> you were going to need it.  :-)

Out of curiosity: is there any downside to having server-start in your
init.el?

Best,

--
Marcin Borkowski
http://mbork.pl

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[João Távora]

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

>
> On Mon, Jun 4, 2018 at 12:29 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> > buffer there that I want to get a hold of.  But I'm at work, and there's
> > no way to make Emacs start a server remotely.
>

Wot no way? Just attach gdb! Then waste rest of workday trying to start a
server
from there!

Now seriously: if it is possible src/.gdbinit could have such a command
pre-baked.

João

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

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 04 Jun 2018 13:29:44 +0200
> 
> 
> It would be really nice if I could just ssh to the machine where the
> Emacs is running, do "kill -USR1 <pid>" and then ... Emacs could do
> something.  Like load "~/.emacs.d/load-file-USR1" or something.  Or just
> start emacs-server.  

The node "Misc Events" in the ELisp manual explains how you can bind
commands to 'sigusr1' and 'sigusr2' pseudo-function keys.  Isn't that
what you want?

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Lars Ingebrigtsen]

Marcin Borkowski <mbork@mbork.pl> writes:

> Out of curiosity: is there any downside to having server-start in your
> init.el?

No, not much.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> Wot no way? Just attach gdb! Then waste rest of workday trying to
> start a server from there!

Heh, I didn't consider that, but that's ingenious.

> Now seriously: if it is possible src/.gdbinit could have such a command
> pre-baked.

Yes, that would be very nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> It would be really nice if I could just ssh to the machine where the
>> Emacs is running, do "kill -USR1 <pid>" and then ... Emacs could do
>> something.  Like load "~/.emacs.d/load-file-USR1" or something.  Or just
>> start emacs-server.  
>
> The node "Misc Events" in the ELisp manual explains how you can bind
> commands to 'sigusr1' and 'sigusr2' pseudo-function keys.  Isn't that
> what you want?

Like I said, if I knew that this was something that I was going to want,
then I would have had it already.

What I'm proposing here is that Emacs should have this functionality by
default, so that anybody can use it when they discover that they need
it.

When they discover the need, it's too late to switch it on, because you
can't talk to an Emacs remotely by default, if you get my drift.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Phil Sainty]

On 2018-06-06 01:31, Lars Ingebrigtsen wrote:
> What I'm proposing here is that Emacs should have this functionality
> by default, so that anybody can use it when they discover that they
> need it.

I think that's a nice idea, personally.  I do run a server as
standard, but I won't clobber an existing server, and I've been
bitten by this issue on occasions when I had multiple emacs instances
running and wanted to access a non-server instance from elsewhere.

By default [sigusr1] and [sigusr2] are bound to 'ignore in
special-event-map, so I don't see why one (or even both) of them
couldn't instead be bound by default to a function which checks to see
whether the file "~/.emacs.d/sigusr1.el" (or 2) exists and, if so,
loads it.

By default that function still wouldn't do very much unless anyone
happens to have such a file existing already, so it doesn't seem like
a totally crazy replacement change from 'ignore (especially if these
signals are only ever sent by users); but people could then create
the file at the time they need it.


-Phil

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 31709@debbugs.gnu.org
> Date: Tue, 05 Jun 2018 15:31:00 +0200
> 
> > The node "Misc Events" in the ELisp manual explains how you can bind
> > commands to 'sigusr1' and 'sigusr2' pseudo-function keys.  Isn't that
> > what you want?
> 
> Like I said, if I knew that this was something that I was going to want,
> then I would have had it already.
> 
> What I'm proposing here is that Emacs should have this functionality by
> default, so that anybody can use it when they discover that they need
> it.

Which functionality? to load a file whose name is fixed in the
sources? because if it isn't fixed, you'd have to prepare the feature
anyway, so it isn't different from binding a key to a function.

Having a fixed file name in Emacs that is loaded by an external signal
would be a terrible security risk, no?

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Which functionality? to load a file whose name is fixed in the
> sources?

Yes.

> Having a fixed file name in Emacs that is loaded by an external signal
> would be a terrible security risk, no?

Well...  Would it?  I mean, the file would be something like
~/.emacs.d/sigusr1.el or something.  To send a signal to the Emacs
process you either have to be the user or root, and if you're the user
or root, you already have all the access to the process that you need to
do, well, anything.  Like it was pointed out here earlier, doing the
"make a running Emacs without a server do something" can be achieved
through gdb magic.

It's just something that's very finicky, and loading a file instead
would be something that a normal user could do.

So: The same attack surface that we already have, but a feature that
would be usable for a normal user.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Phil Sainty]

On 2018-06-06 02:38, Eli Zaretskii wrote:
> Having a fixed file name in Emacs that is loaded by an external signal
> would be a terrible security risk, no?

Bad Things could surely be done; but if the attacker has access to
send signals to the user's emacs process or write files in the user's
~/.emacs.d directory, has a terrible security breach not already
occurred?  The notion of an attacker gaining access to a running Emacs
session is certainly bad, but I'm unsure whether the proposed idea
really worsens the risk in principle?

-Phil

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 31709@debbugs.gnu.org
> Date: Tue, 05 Jun 2018 17:21:46 +0200
> 
> So: The same attack surface that we already have, but a feature that
> would be usable for a normal user.

I'm not an expert, but you get to argue with those who are ;-)

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Phil Sainty]

On 2018-06-06 03:35, Phil Sainty wrote:
> On 2018-06-06 02:38, Eli Zaretskii wrote:
>> Having a fixed file name in Emacs that is loaded by an external signal
>> would be a terrible security risk, no?
> 
> Bad Things could surely be done; but if the attacker has access to
> send signals to the user's emacs process or write files in the user's
> ~/.emacs.d directory, has a terrible security breach not already
> occurred?  The notion of an attacker gaining access to a running Emacs
> session is certainly bad, but I'm unsure whether the proposed idea
> really worsens the risk in principle?

In fact if you normally run emacs as a server you're opening up the
same security risk, no?  An attacker who could send a signal to an
emacs process can also run emacsclient to access an existing server;
and I don't think we consider the practice of running an emacs server
to be a terrible security risk.


-Phil

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Which functionality? to load a file whose name is fixed in the
>> sources?
>
> Yes.
>
>> Having a fixed file name in Emacs that is loaded by an external signal
>> would be a terrible security risk, no?
>
> Well...  Would it?  I mean, the file would be something like
> ~/.emacs.d/sigusr1.el or something.  To send a signal to the Emacs
> process you either have to be the user or root, and if you're the user
> or root, you already have all the access to the process that you need to
> do, well, anything.  Like it was pointed out here earlier, doing the
> "make a running Emacs without a server do something" can be achieved
> through gdb magic.

I believe said gdb magic requires you to have ptrace capabilities on
the process in question, which is a stronger requirement than being
able to send a signal (unless youʼre root, of course).

> It's just something that's very finicky, and loading a file instead
> would be something that a normal user could do.
>
> So: The same attack surface that we already have, but a feature that
> would be usable for a normal user.

A slightly larger attack surface, I think. But more convenient to
use. Although you could just bind server-name to something based on
the current pid, and then run (server-start) in all your emacsen.

Robert

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Robert Pluim]

Phil Sainty <psainty@orcon.net.nz> writes:

> On 2018-06-06 03:35, Phil Sainty wrote:
>> On 2018-06-06 02:38, Eli Zaretskii wrote:
>>> Having a fixed file name in Emacs that is loaded by an external signal
>>> would be a terrible security risk, no?
>>
>> Bad Things could surely be done; but if the attacker has access to
>> send signals to the user's emacs process or write files in the user's
>> ~/.emacs.d directory, has a terrible security breach not already
>> occurred?  The notion of an attacker gaining access to a running Emacs
>> session is certainly bad, but I'm unsure whether the proposed idea
>> really worsens the risk in principle?
>
> In fact if you normally run emacs as a server you're opening up the
> same security risk, no?  An attacker who could send a signal to an
> emacs process can also run emacsclient to access an existing server;
> and I don't think we consider the practice of running an emacs server
> to be a terrible security risk.

What if this hypothetical emacs was deliberately started without a
server running, since it contains sensitive information? Starting a
server when receiving a signal has now opened up access to that emacs
where none existed before.

Robert

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Phil Sainty]

On 2018-06-06 04:24, Robert Pluim wrote:
> Phil Sainty <psainty@orcon.net.nz> writes:
>> In fact if you normally run emacs as a server you're opening up the
>> same security risk, no?  An attacker who could send a signal to an
>> emacs process can also run emacsclient to access an existing server;
>> and I don't think we consider the practice of running an emacs server
>> to be a terrible security risk.
> 
> What if this hypothetical emacs was deliberately started without a
> server running, since it contains sensitive information? Starting a
> server when receiving a signal has now opened up access to that emacs
> where none existed before.

Certainly -- if we *are* treating emacs servers in general as a security
risk, then the concern seems valid.

-Phil

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Phil Sainty]

On 2018-06-06 04:36, Phil Sainty wrote:
> On 2018-06-06 04:24, Robert Pluim wrote:
>> What if this hypothetical emacs was deliberately started without a
>> server running, since it contains sensitive information? Starting a
>> server when receiving a signal has now opened up access to that emacs
>> where none existed before.
> 
> Certainly -- if we *are* treating emacs servers in general as a 
> security
> risk, then the concern seems valid.

Of course if the attacker can edit files in the user's ~/.emacs.d then
there's already nothing to stop them from adding a custom [sigusr1]
binding to the user's init file or some other loaded file in their
config (or site-start.el or a core library if they had root), and
enabling the behaviour we're discussing for the user's future emacs
sessions (albeit in a way which might be more apparent to the user,
depending on how they manage their config).

-Phil

bug#31709: 27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?

[Lars Ingebrigtsen]

There didn't seem to be much enthusiasm for this feature, so I'm closing
this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no