GNU bug report logs -
#31709
27.0.50; Wishlist: Perhaps Emacs should load a file when getting a particular signal?
Previous Next
Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Mon, 4 Jun 2018 11:31:02 UTC
Severity: wishlist
Tags: wontfix
Found in version 27.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31709 in the body.
You can then email your comments to 31709 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Mon, 04 Jun 2018 11:31:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lars Ingebrigtsen <larsi <at> gnus.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 04 Jun 2018 11:31:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Mon, 04 Jun 2018 12:30:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 31709 <at> debbugs.gnu.org (full text, mbox):
On 2018-06-04, at 13:29, Lars Ingebrigtsen <larsi <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Mon, 04 Jun 2018 14:54:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 31709 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> On Mon, Jun 4, 2018 at 12:29 PM, Lars Ingebrigtsen <larsi <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Mon, 04 Jun 2018 16:04:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 31709 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 13:28:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 31709 <at> debbugs.gnu.org (full text, mbox):
Marcin Borkowski <mbork <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 13:29:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 31709 <at> debbugs.gnu.org (full text, mbox):
João Távora <joaotavora <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 13:32:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 31709 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 14:30:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 31709 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 14:39:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 31709 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 31709 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 15:22:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 31709 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 15:36:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 31709 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 15:46:03 GMT)
Full text and
rfc822 format available.
Message #38 received at 31709 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 31709 <at> 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 ;-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 15:52:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 31709 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 16:22:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 31709 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 16:25:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 31709 <at> debbugs.gnu.org (full text, mbox):
Phil Sainty <psainty <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 16:37:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 31709 <at> debbugs.gnu.org (full text, mbox):
On 2018-06-06 04:24, Robert Pluim wrote:
> Phil Sainty <psainty <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Tue, 05 Jun 2018 17:06:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 31709 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#31709; Package
emacs.
(Sat, 21 Sep 2019 08:20:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 31709 <at> debbugs.gnu.org (full text, mbox):
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
Added tag(s) wontfix.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 21 Sep 2019 08:20:04 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
31709 <at> debbugs.gnu.org and Lars Ingebrigtsen <larsi <at> gnus.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 21 Sep 2019 08:20:04 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 19 Oct 2019 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 189 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.