GNU bug report logs -
#39563
default location of backup files
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39563 in the body.
You can then email your comments to 39563 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#39563
; Package
emacs
.
(Tue, 11 Feb 2020 14:42:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pedro Moreira <pedro.moreira <at> ipbeja.pt>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 11 Feb 2020 14:42:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello!
if a user edits a php file using emacs directly at the webserver, emacs
automatically saves a temp file at the same location, for example the
user opens index.php, emacs stores a copy index.php~.
Therefore the code in that file is exposed. If an attacker tries to
access files like https://domain.com/index.php~ the server wont
interpret that file as php and presents it as plain text exposing the
source code.
I know this could be resolved with webserver configuration. But it is a
problem i just discovered and leaves me very unconfortable using emacs.
Maybe should be better the temp file beying stored like index~.php or
index.bck.php.
Thanks
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39563
; Package
emacs
.
(Tue, 11 Feb 2020 15:09:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 39563 <at> debbugs.gnu.org (full text, mbox):
On Feb 11 2020, Pedro Moreira wrote:
> if a user edits a php file using emacs directly at the webserver
Surely you shouldn't be doing that with any editor.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39563
; Package
emacs
.
(Tue, 11 Feb 2020 15:16:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 39563 <at> debbugs.gnu.org (full text, mbox):
On 11.02.2020 13:32, Pedro Moreira wrote:
> Therefore the code in that file is exposed. If an attacker tries to
> access files like https://domain.com/index.php~ the server wont
> interpret that file as php and presents it as plain text exposing the
> source code.
Would it be better for the server to interpret it as PHP code and allow
an arbitrary visitor to run whatever intermediary version of your code
that's in the backup?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39563
; Package
emacs
.
(Tue, 11 Feb 2020 16:52:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 39563 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Greetings!
On Tue, Feb 11, 2020, 08:43 Pedro Moreira <pedro.moreira <at> ipbeja.pt> wrote:
> Hello!
>
> if a user edits a php file using emacs directly at the webserver, emacs
> automatically saves a temp file at the same location, for example the
> user opens index.php, emacs stores a copy index.php~.
>
> Therefore the code in that file is exposed.
>
Editing files directly under the server root while the server is running is
a bit risky to start with. If you can use any sort of CI that will
generally pay dividends in terms of "an ounce of prevention".
>
> I know this could be resolved with webserver configuration.
Whether or not any of the Emacs condig changes I mention in the rest of the
message seem useful, for Apache httpd 2, I definitely recommend something
like:
IgnoreIndex *~
<Files "*~$">
order allow deny
deny from all
</Files>
For myself, I would focus on the Emacs side of the equation, considering
first if I want backs in the situations, where they should be, and so
forth.
https://www.gnu.org/software/emacs/manual/html_node/elisp/Making-Backups.html
Unless you/users happen to be accessing via remote Emacs sessions, in which
case maybe you prefer something like :
(add-to-list 'backup-directory-alist
(cons tramp-file-name-regexp nil))
Or look at:
enable-remote-dir-locals which could be used to set a backup disable (or
storage plan) configabove in a .dirs-local file kept on the server. This
setting would have to be configured on a given Emacs that is remotely
accessing your web-server for the dirs-local file to be honored when using
tramp to exit server files in place via remote emacs.
But it is a
> problem i just discovered and leaves me very unconfortable using emacs.
>
Point taken. I note this is called out in documentation for tramp although
the example given is exposing ssh config info not raw delivery of
server-side source.
I can see an argument that the defaults, which enable backup on on save by
renaming the original after appending a ~, could benefit from some
defensive special case behaviour. For example, when tramp picks up autosave
defaults, it could potentially use some of the special casing for su and so
forth floating around EmacsWiki without taking away configures
functionally. Some, at least, probably won't prefer this as a default.
That said, special casing that would respect a path under an httpd2
document root or what-have-you seems like it should be the domain on a
dedicated program that knowns a bit about web server products and can
supply good defaults or otherwise use the servers config to DWIM.
Maybe should be better the temp file beying stored like index~.php or
> index.bck.php.
>
Options to set this up exist also, although i
I haven't setup anything like this so far. This is what I would look at,
except that, in the event I use the apache rule similar to the above
because I *do* want in place backups anytime I find myself hot-patching
under a doc-root but I don't want them shown when I allow directory index.
(I currently allow access to the file if you know the name, which I
probably should not. In my setup if you can figure out the name of the
script that handles /foo/bar you can probably read HEAD-1 of source by
hitting the backup file directly.)
> Thanks
>
Is any of this helpful?
>
[Message part 2 (text/html, inline)]
Changed bug title to 'default location of backup files' from 'temp files'
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Mon, 17 Feb 2020 03:26:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39563
; Package
emacs
.
(Mon, 30 Aug 2021 01:23:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 39563 <at> debbugs.gnu.org (full text, mbox):
Pedro Moreira <pedro.moreira <at> ipbeja.pt> writes:
> if a user edits a php file using emacs directly at the webserver,
> emacs automatically saves a temp file at the same location, for
> example the user opens index.php, emacs stores a copy index.php~.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
You can make Emacs save backup files somewhere else, like this, for
instance:
(setq backup-directory-alist
'((".*" . "~/.emacs.d/aux/")))
While it's a concern that you could expose data if you're editing your
running php files directly, I don't there's anything much Emacs can do
to auto-detect that. 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
.
(Mon, 30 Aug 2021 01:23:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
39563 <at> debbugs.gnu.org and Pedro Moreira <pedro.moreira <at> ipbeja.pt>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 30 Aug 2021 01:23:02 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
.
(Mon, 27 Sep 2021 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 268 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.