One of the times when many emacs-users still reach for vi is when editing
system configuration files – the stuff in /etc/, etc. I think that is
because of the now mostly false impression that emacs startup is slow, and
because people don't want to run an open-ended program as emacs as root.
There is truth in that last point – but it applies just as well to, say,
vim. Anyway, running emacs as root is not a good idea.
So how what can we do it? Easy! Using the tramp package (included with
GNU/Emacs since version 22), you can run emacs as a normal user, but edit
root-and-other-owned files. It does its magic using sudo, but you won't
normally notice. It does require you to have sudo-rights of course.
How does this work? Well, instead of
C-x C-f /etc/hosts
to open a file as a normal user, you use:
C-x C-f /sudo:root@localhost:/etc/hosts
or even shorter, as noted by Alexander Kojevnikov (because Tramp defaults to
root@localhost):
C-x C-f /sudo::/etc/hosts
It asks for a password - and you should use your user password for that (not
the root password!). This usually works fine, but due to way Tramp works, it
can get confused if root has some very weird command prompt. If
so, you of course configure tramp. Also note that sudo usually remembers
that you logged in, an does not require you to re-enter you password when
opening ('visiting') another file for some time period – but you can change
this. See the sudo(8).
This automatically invokes tramp which does all the magic for you. If you
don't like the somewhat longer (pseudo)paths for files, you can of course use
the emacs bookmarks facilty. After you load the file, you can use it like any
other file.
Note, this is only of the many useful things you can do with Tramp. Tramp
was actually written for editing files on remote machines (using ssh or
other protocol), and I very happily used it to edit files on some European
machine whilst in Australia. It caches the file locally, and only sends it
over when you save it, so it very fast – it simply makes you forget your file
is so far away.
19 comments:
Sudo isn't necessary, you can access your files using "/re:/path/to/the/file".
You can also omit the root@localhost part:
C-x C-f /sudo::/path/to/the/file
I like using vi to edit system configuration files because I don't end up with backup~ files scattered around the system.
@Anonymous:
Just add this to you .emacs:
(setq make-backup-files nil)
@Alexander Kojevnikov: thanks, updated. Forgotten about that one...
@Anonymous:
You could also put in your .emacs:
-----
(setq backup-directory-alist
'(("." . "~/.emacs.backups")))
------
to put all your backups in ~/.emacs.backups
There's a typo in the post. Instead of "C-x C-f", it mentions "C-x f".
To make /sudo:: work with zsh I'm using
(setq tramp-shell-prompt-pattern "^[^$>\n]*[#$%>] *\\(\[[0-9;]*[a-zA-Z] *\\)*")
@g13n: whoops! fixed, thanks.
Hey this is really cool!
Now the only thing I'm missing is that often I need to edit a config file on a remote host but can only ssh to that host as a user and have to do sudo on the remote host so that I'm allowed to edit the file. Anybody knows if this works with tramp too?
@djcb: you misspelled my surname :)
There's also the tramp-backup-directory-alist variable especially to set the backup directory during tramp usage, separately from the usual backup directory.
@til: I suppose that's one of the cases tramp multi-hop methods are for.
@Alexander Kojvevnikov -- sorry, fixed now.
@Rörd thanks, multihop works for that purpose, I got it working after some fiddling.
A minor inconvenience is that apparently one has to specify the hosts one wants to sudo on beforehand in the tramp-default-proxies-alist variable and can not use the multi: method anymore as described here: http://www.gnu.org/software/emacs/manual/html_node/tramp/Multi_002dhop-filename-syntax.html
Anyway, opening up remote files like this /sudo:example.com:/etc/hosts works now, yeah!
Pardon my ignorance, I wonder if you could elaborate further on why running emacs as root (or presumably as a privileged user) is not a good idea?
@Dave: well, you want to do as little as possible with root privs, for security reasons or simply safety against user screw-ups. A (theoretical) exploit in e.g. gnus or w3m would be much more serious when running as root.
@djcb: Thanks, perhaps I should have directed my question more precisely: What is it about emacs that suggests it is a poor choice for editing system files that require privileged access.
Is this an estimate/rule of thumb based on the probability of exploits vs. size of the project? Or is there something more specific?
@Dave: this is just some cautionary paranoia against big, open-ended program; I guess it correlates with size/complexity/maturity/ etc., but it's hard to quantify. Not running as root may help a bit, so we might as well do that.
Late to the show but:
@Dave: I usually list emacs as one of my Operating Systems in my skillsset. That's a lot of power to use on just editing a file, unless you get in and get out. Even the /sudo::/ trick leaves you a tiny bit vulnerable.
Post a Comment