Greetings!
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.
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.)
Is any of this helpful?