An irc-user in #Vim urged me not to use Sudo with Vim like:

sudo vim bad_idea


When I am doing things in locations such as /var/www/, I cannot write without it. So not-using sudo becomes a problem. Of course, I could make changes in different locations such as /tmp/ and then copy dirs to /var/www. However, I sense an easier way.

1. If you do not "sudo Vim", why?
2. If yes to 1st question, how do you circumvent problems not to use sudo?
-

I fall under the first category: sudo vim /var/www/html/some_file is a bad idea; it allows shell escapes that aren't logged. Instead, use sudoedit /var/www/html/some_file; that has the same effect.

-
What are "shell escapes that aren't logged"? and why doesn't only matter in /var/www? –  hasenj Sep 11 '09 at 2:58
vim has the power to run other commands on a command line. However, because vim was started via sudo, and is therefore running as root, any of those commands will run with root privileges. These commands are known as "shell escapes" and aren't logged the way other invocations of sudo are. And it's not restricted to just /var/www; it's everywhere that I'd use it. I've even aliased "sudo vi" to "sudoedit" in my bashrc file. –  Kevin M Oct 21 '09 at 15:32
I see what you're getting at and want to agree but clarify. We have no idea whether his normal su and sudo root activities are being logged or not. "sudo vim" allows running a subshell as root - that much is accurate; within that shell, "sudo" won't be controlling what root can and can't do. –  pbr Nov 25 '09 at 16:57
Kevin, how did you manage to alias "sudo vi" to "sudoedit"? From the bash manual... "The characters /, $, , and = and any of the shell metacharacters or quoting characters listed above may not appear in an alias name." ...space is one of those metacharacters it's talking about. – pbr Nov 25 '09 at 16:58 OK, so it's not an alias per se, but it has the same effect: 'function sudo () { [[$1 == vi ]] && shift && sudoedit "$@" || command sudo "$@"; }' –  Kevin M Dec 18 '09 at 20:21

% is replaced with the current file name, thus you can use:

:w !sudo tee %

-
If you're going to use tee, I'd suggest ':w !sudo tee % >/dev/null' so you don't see the entire file echoed back at you. I typically use ':w !dd of=%' instead since it's quicker to type and achieves the same thing. Of course, this is only when I've forgotten to use sudoedit/sudo -e. –  jamessan Nov 2 '09 at 22:24

vim allows users to execute arbitrary shell commands, therefore many system admins do not allow vim to be used with sudo.

rvim is included with vim. It is a restricted vim, that does not allow shell commands. (Or allow you to suspend vim, for the same reasons.)

Whether you need to go to those extremes on your own box is debatable.

-
+1. Completely agree. sudo vim then enter :!bash and you have a shell as root - exactly why rvim exists –  dbr Sep 4 '09 at 13:12
Actually if you can sudo vim, you can probably sudo bash or sudo su - right? –  dlamblin Sep 15 '09 at 0:29
@diamblin Privileges can be mustered out with finer detail than that, so not necessarily. That is why rvim is needed. "sudo vim" is the same as "sudo su -" for all intents and purposes. On a Debian bitty-box where the one user is the system administrator though, this is all academic. –  Richard Hoskins Sep 15 '09 at 4:15
How does ubuntu deal with this issue? On CentOS vi launches vim but as root vi launches vi. On Ubuntu vim is used in both cases and sudo vi also launches vim... –  cwd Dec 13 '11 at 2:20

When editing system-wide configuration files, it's totally okay---just always remember you're root and thus have all the power, and drop those privileges as soon as you don't need them anymore.

In the special case /var/www/, i.e. web server pages, you might want to think about changing some ownerships / groups / permissions---but if and how largely depends on your particular setup (single / multi user, real web server / just localhost, dynamic / static, etc.)

-
+1 for changing ownerships/groups/permissions. –  Kevin M Aug 16 '09 at 18:21
+1 indeed -- this is the best way of handling web-server pages. Make sure you have access to them rather than elevating your privileges. –  bedwyr Aug 16 '09 at 18:23
-1 there's no reason to run vim with elevated privileges when sudoedit will do the same job. –  sml Sep 21 '10 at 6:23

A question like this makes me smack my forehead. I am on the other side of security, "security should not interfere with the user experience, unless it is expected or required to prevent the average person doing malicious activity."

Preventing sudo use of vim is just a band aid. As stated earlier, someone can just use:

sudo su -


Or

sudo /bin/bash


Or

sudo nano file


Or

sudo my_exectuable_text_editor file


ect

If you are really worried about someone doing something malicious on the box, do not give them sudo (or root password obviously) privileges, period. There is no sliver bullet to prevent malicious activity using sudo and you will only drive yourself crazy by "applying" all the "fixes" to make sure a person can't do anything malicious.

Someone mentioned changing ownership/groups. This is a sticky problem as if the web server is ran as another user, and you change permissions on the file, now all of a sudden your site doesn't work. Well, obviously that wont help you. You can add yourself to the group the web server runs as, however, if the group doesn't have write access to the files, you would need to perform chmod -R g+w * (or chmod individual files) which may not be what you want and can be a hassle if you have to chmod every file.

Some people even suggested using rvim. Sure, one could just add a line in /etc/sudoers to only allow certain users to sudo rvim, however, it would logically stand that if you had to go that route, it may just be better to implement a web based file manager. This way it is running as the user the web server is running as, thus no file permission issues and you can still have granular control over who edits what files.

My two cents anyways.

-

Running sudo vim won't change the $HOME directory, so you will be running Vim with root permissions, but $HOME is still pointing to your normal user.

If this is the first time you are running Vim, it may happen that ~/.viminfo file is created inside your normal user directory, but with root permissions.

-
Depends on the sudo. On my laptop sudo vim -c '!echo \$HOME' -c q does give my home folder, but on my server it gives /root. I might have to take a look at why that is, could be because one's OS X while the other's Gentoo, or could be something to do with how /etc/sudoers` is setup. –  Nemo157 Jun 25 '13 at 6:03

IF THIS IS YOUR OWN COMPUTER... I see no reason why you can't use 'sudo vim', other than the edge case that Denilson noted - that it might create your ~/.viminfo owned by root.

If not - if a systems administrator is restricting what you can and can't do - per "man sudo": "on most systems it is possible to prevent shell escapes with sudo's noexec functionality. See the sudoers(5) manual for details."

So in this case, if your sysadmin is concerned about the potential of you running subshells as root from within vim, they can use the noexec capability. But... back to the initial case - if this is YOUR computer, I think you're pretty darn safe running 'sudo vim'.

-