On a linux machine, a non-root user open a file,

$ sudo vi /etc/hosts

and quit saying :sh

to get root access.

1) With above, How a non-root user becomes a root user?

2) Why Linux allow such hacking approach to breach security?

  • 7
    Non-root users have that privilege because root gave it to them in the sudoers configuration files. If you have users on your system that you don't trust with such access, edit the sudoers files. See man visudo and man sudoers for more info. (As for why some distributions provides such privileges as a default, I'll leave that to someone else to explain/defend.)
    – John1024
    Mar 10, 2018 at 1:40
  • 8
    What am I missing that a non-root user has sudo vi access and you don't expect him to get root? It occurs to me that even if :sh didn't work getting root by opening vi or vi filename is easy.
    – Joshua
    Mar 10, 2018 at 2:53
  • 6
    If they have access to sudo, they don't even need to go through Vi, they can just directly do sudo bash and, poof, root. "sudo" means "super user do"; if people have access to that, they may as well be root, because they can do anything root can.
    – anon
    Mar 10, 2018 at 4:15
  • 3
    Who configured sudo vi to be allowed without understanding they were giving the user full root privileges? Mar 10, 2018 at 18:26
  • 1
    @overexchange Because sudo command runs command as root. If that's the command bash, it starts a new terminal as root. If that's the command apt-get install emacs24, it runs apt-get with those arguments, and it runs it as root.
    – anon
    Mar 11, 2018 at 22:52

2 Answers 2


The non-root user became root as soon as they successfully ran sudo (given the assumed root target user); they started running vi as root. When you ask vi for a shell, it dutifully runs a shell, as the current user -- root! I should clarify that you should not "quit" vi with the :sh command, as that's asking for a shell. Quit with :q instead.

Linux allows such functionality because that's specifically what sudo is intended to do! Perhaps you've seen the lecture that sudo gives:

We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.

#2) Think before you type.

#3) With great power comes great responsibility.

sudo offers a limited "speed bump" to this when it comes to granting "ALL" access, in the form of the ! negation operator, often demonstrated as:

jill        SERVERS = /usr/bin/, !SU, !SHELLS

where jill is granted permission to run programs from /usr/bin, but not anything listed in the SU or SHELLS aliases.

The sudoers man page has a whole "Security Notes" section when it comes to granting large-scale access via sudo and then trying to restrict it.

Limitations of the ‘!’ operator

It is generally not effective to “subtract” commands from ALL using the ‘!’ operator. A user can trivially circumvent this by copying the desired command to a different name and then executing that.


In general, if a user has sudo ALL there is nothing to prevent them from creating their own program that gives them a root shell (or making their own copy of a shell) regardless of any ‘!’ elements in the user specification.

and more pertinently:

Preventing shell escapes

Once sudo executes a program, that program is free to do whatever it pleases, including run other programs. This can be a security issue since it is not uncommon for a program to allow shell escapes, which lets a user bypass sudo's access control and logging. Common programs that permit shell escapes include shells (obviously), editors, paginators, mail and terminal programs

  • 1
    Thank you for including the "preventing shell escapes" bit. It's a lesser-known feature. You might want to include an example showing how to do a positive program restriction, rather than just warn against the negative cases; one way to show this is with the classic example of a "backup" group which is only allowed to run dump and tar. Mar 10, 2018 at 4:29
  • 6
    @WarrenYoung if I can pass any arguments I want to tar then I can almost certainly use it to overwrite some files in a way that will give me more permissions. It's very hard to give someone "just a little bit" of root.
    – hobbs
    Mar 10, 2018 at 7:29
  • 1
    @WarrenYoung Exactly as hobbs says. I would get root with a tar; you just replace passwd, the easiest way to do it. Mar 10, 2018 at 8:09
  • 1
    @RuiFRibeiro Or by replacing /etc/sudoers with a less restricted configuration.
    – user130738
    Mar 10, 2018 at 9:46
  • 2
    @PeterCordes That´s more or less one of the ways I hacked a server at faculty in an age without much common sense. Then I played some harmless pranks with the classmates, and as the professors told you will be graded by computer time, stole all logins less than 2 minutes to my account. The professors knew...I was invited as sysadmin a couple of years later on for an associated organisation. Mar 10, 2018 at 21:27

If sudo vi /etc/hosts is successful, it means that the system administrator has allowed the user to run vi /etc/hosts as root. That's the whole point of sudo: it lets the system administrator authorize certain users to run certain commands with extra privileges.

Giving a user the permission to run vi gives them the permission to run any vi command, including :sh to run a shell and :w to overwrite any file on the system. A rule allowing only to run vi /etc/hosts does not make any sense since it allows the user to run arbitrary commands.

There is no “hacking” involved. The breach of security comes from a misconfiguration, not from a hole in the security model. Sudo does not particularly try to prevent against misconfiguration. Its documentation is well-known to be difficult to understand; if in doubt, ask around and don't try to do things that are too complicated.

It is in general a hard problem to give a user a specific privilege without giving them more than intended. A bulldozer approach like giving them the right to run an interactive program such as vi is bound to fail. A general piece of advice is to give the minimum privileges necessary to accomplish the task. If you want to allow a user to modify one file, don't give them the permission to run an editor. Instead, either:

  • Give them the permission to write to the file. This is the simplest method with the least risk of doing something you didn't intend.

    setfacl u:bob:rw /etc/hosts
  • Give them permission to edit the file via sudo. To do that, don't give them the permission to run an editor. As explained in the sudo documentation, give them the permission to run sudoedit, which invokes an editor as the original user and then uses the extra privileges only to modify the file.

    bob ALL = sudoedit /etc/hosts

    The sudo method is more complicated to set up, and is less transparent for the user because they have to invoke sudoedit instead of just opening the file in their editor, but has the advantage that all accesses are logged.

Note that allowing a user to edit /etc/hosts may have an impact on your security infrastructure: if there's any place where you rely on a host name corresponding to a specific machine, then that user will be able to point it to a different machine. Consider that it is probably unnecessary anyway.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .