You are an administrator, but not
root user can do anything. Administrators can perform actions as
root, but ordinarily what administrators do is not done by
root. That way, you have full control over your own system, but only when you choose to use it.
Ubuntu asks for your password when you try to do stuff as
root, to make sure it's really you.
User Accounts: Human, and Otherwise
Real human users have user accounts to represent them. You created one such account when you installed Ubuntu. But not all user accounts represent real human users.
Real human users are granted (and denied) abilities through their user accounts. They must use their user accounts to use the system; therefore, their user accounts' abilities and limitations apply to them.
User accounts are also used to codify sets of abilities and limitations. Some user accounts--most, actually, unless you have many human users of the machine--exist so that certain programs or commands can be run with their identity, an identity with the right abilities and limitations for the job.
For example, the
www-data user exists so that if you run a web server, it owns the data the server make accessible. No real human user has to be empowered to make unchecked changes to those data, and the web server doesn't have to be empowered to perform any action unnecessary for serving the web. Consequently, both the web data and the rest of the system are more secure against accidental or intentional breakage, than if the web server were run by some human user who would have all the powers of the web server (and whose powers the web server would possess).
The Most Important Non-Human User Account
The superuser, whose username is
root, is a non-human user account with a very specific combination of abilities and limitations: all abilities, and no limitations.
root's allowed to do anything. There are still things
root cannot do because the system itself cannot perform or make sense out of them. So
root cannot kill a process that is in uninterruptible sleep, or make a rock too heavy to move, then move it.
Many important system processes, like
init, run as
root is used for performing administrative tasks.
Can I log in as
It's possible to configure the
root account so it's possible to log in with a password, but this is not enabled by default in Ubuntu. Instead, you can think of
root as being like
nobody, and other non-human accounts. (Run
cat /etc/passwd or
getent passwd to see them all.)
Human users log in with their own user accounts, and then if some task is to be performed with another user account, they cause that task to be performed with that identity, without actually having logged in as that user.
It's possible to configure the other non-human users, like
www-data, so one can log in as them, too. That's quite rare, though, whereas in some other Unix-like OSes it's common to log in as
root in a terminal. The risks of running a whole graphical interface as
root, combined with how many graphical programs are not designed to run as
root and may not work properly, mean that you should never attempt to get a
root-owned desktop session.
Please note that while logging in as
root is disabled by default in Ubuntu, there are ways to get a
root shell without authenticating as
root, which produce a similar effect: the most common are
sudo -s or
-i, recovery mode and similar techniques. (Don't worry if you don't know what those things are.) This is not actually logging in: in recovery mode, you become
root before any login would occur; with the
sudo-based methods, you're just running a shell as root.
In Ubuntu, administrators are the users who can do whatever they want as
root, when they choose to do so.
System Settings > User Accounts. "Eliah Kagan" is an administrator, so he can do stuff as
root, but he is not
I'm an administrator on my Ubuntu system. When I run programs, ordinarily they run as
ek ("Eliah Kagan" is the full name that corresponds to the
When I run AbiWord or LibreOffice, it runs as
ek. When I run Firefox, Chromium, Empathy, or Pidgin, it runs as
ek. The programs that run to provide the desktop interface run as
However, I am an administrator, so if I need to perform an administrative task, I can do so.
On the command line, I would ordinarily use
sudo to run a command as
This will prompt me for my password. (Not
root does not have one.)
- Because I am an administrator, I can perform actions as
root. In the default configuration, I must enter my password to do this.
- Users who are not administrators cannot perform actions as
root, even by putting in their password.
sudo commands will fail if the user running them is not an administrator.
Because administrators are perfectly ordinary users except for the ability to perform actions as
root, running a command requiring
root privileges will still fail, except when the command is run as
Screenshot illustrating the need to use
sudo to perform administrative tasks. (Based on "Sandwich" by Randall Munroe.)
Graphical programs can run as
root through graphical frontends for
sudo, such as
kdesudo. For example, to run GParted as
root I could run
gksudo gparted. Then I would be prompted graphically for my password.
Since I'm prompted graphically, there doesn't have to be a terminal. This is one of the ways administrative tools are run as
PolicyKit is another way for administrators to do things as
root. A program accesses a service that performs the action. Sometimes, the action is running a whole program; sometimes the action is more limited.
These days, many graphical system administration utilities are set up to use PolicyKit by default, rather than to use
One example of such a utility is the Software Center. It takes full advantage of PolicyKit, requiring the user to put in their password only when they want to do something that requires
root privileges. (This is possible with
sudo-based authentication also, but it is harder and uglier to accomplish.)
In the Software Center, I can find and read about an application; then I'm asked for my password when I want to install it.
How PolicyKit Is Different
Any graphical program can be run as
gksudo and other graphical
sudo frontends. (The program might not work very well, depending on whether or not it's designed to be used as
root. But the command to start the program will be executed as
While PolicyKit is now more common than
sudo GUI frontends as the way applications on Ubuntu perform actions as
root behind the scenes, PolicyKit will only run a graphical application as
root if there is a configuration file allowing it and indicating what actions may be performed.
pkexec is the command used to run a program with PolicyKit.
pkexec can run non-graphical commands. (And it does not require a configuration file defining the command's capabilities--it simply runs the command as
pkexec prompts for a password graphically, even if it is run from a Terminal (this is one of the ways its behavior is more similar to
gksudo than to running straight
(If there is no GUI--for example, if you're logged in from a virtual console or text-only SSH session, or the GUI is not functioning properly--then
pkexec will degrade gracefully and prompt for your password on the command line.)
Once authentication is performed successfully, the command runs in the terminal.
Running Commands as Other Users Besides
root is special because it gets to do anything that can be done. But it's a user account like any account, and the ways of running commands as
sudo (directly or with a graphical frontend) or PolicyKit can be modified slightly to run a command as any other user:
sudo -u username command...
gksudo -u username command...
pkexec --user username command...
What? You just type
sudo first? How is that security?!
Running commands with
sudo is sort of like invoking papal infalliblity.
When you run a command with
sudo [invoke papal infallibility], Ubuntu [Catholic folks] tries hard to make sure you're really you [really the Pope].
Yes, I know papal infallibility (even when normative) is declarative; the parallel is not perfect.
Trying to do something as
sudo (or PolicyKit) is a big deal--Ubuntu is not just going to let that slide by like all the other times you run a program.
You are prompted for your password. (Then, that you have done so is remembered for a short time, so you don't have to constantly enter your password as you administer your system.)
Besides reminding you to be careful, this safeguards against two scenarios:
- Someone uses your computer (or mobile device), maybe under the guise of checking their email or some similar innocuous purpose. Here, it's still possible for them to do some harm--for example, they could modify or delete your documents. However, they cannot administer the system, since they cannot put in your password.
- Programs that aren't supposed to administer the system cannot do so, unless you enter your password. For example, if your web browser is compromised by a security bug and runs malicious code, it still cannot perform administrative tasks. It cannot create and delete users, modify programs installed as
root (which includes anything installed by the package manager, such as LibreOffice), or alter the system at a deep level.
I've heard of
su. What's that? Can I use that?
su authenticates as another user, and runs a command (or starts an interactive shell). It's possible to limit who is permitted to use
su authenticates with the target account's password, not the password of the user running.
su username -c 'command...' runs
command... as username, just like
sudo -u username command....
But when you run a command as
sudo, you enter your password. When you run a command as
su, you enter
su performs authentication for the target user, with
su you can only run commands as users whose accounts are enabled.
root account (like
nobody) is disabled by default. There is no password that will work to log in as
root. So you cannot use
su to run commands as
You can use
su to run commands as another user who can log in (which typically includes all the user accounts on your system that represent human beings).
When logged in as a guest, you cannot use
su at all.
Someone who is not an administrator can even use
su to run
sudo as an administrator. (This is OK though, as they need the administrator's password to run commands as the administrator.) That is, a limited user can use
su to run
sudo to run a command as
root. This can look like:
su username -c 'sudo command...'
(Running graphical programs this way requires special care.)
su be a more secure way to run commands as
What if a user shouldn't be allowed to act as
Make them a limited user instead of an administrator.
What if a program running as an administrator tries to
Unless you have reconfigured
sudo to let it succeed without a password, it will fail.
Can't a program that shouldn't be run as
root piggyback on a recent
sudo command, so no password is required?
This would be very unlikely to succeed. These days, most operating systems (including Ubuntu) have
sudo configured by default so that its timestamps apply only in a specific context.
For example, if I run
sudo ... in one Terminal tab and authenticate successfully,
sudo in another tab (or run by an unrelated GUI program, or that I run from a virtual console or SSH session) will still prompt for a password. Even if it's run immediately afterwards.
Doesn't a program running as user X have access to user X's password?
If a malicious program is able to run as an administrator, can't it "listen in" to what's being typed when the administrator authenticates with
sudo or PolicyKit?
Potentially, yes. But then it could "listen in" to a password typed in for
If I tell someone my password—
Don't tell people your password.
What if someone has to know my password to do something on my behalf, but I don't want to let them administer the system?
Ideally, they should have a separate user account that lets them do what they need to do. For example, can share files between accounts, allowing multiple user to write to them, while still denying access to other users.
However, in a situation where a less-trusted person may be permitted to share your account, it should be a limited user account. You could make a separate account for this purpose (which makes sense--if it's an account for you and someone else who you want to have different capabilities, it should be a different account).
So, would the most secure thing be to disallow both
su and make people log in as
No, because there are serious disadvantages associated with letting people log in as
root at all. Whenever possible, the smallest number of actions as possible should be undertaken as
root. Even most acts relating directly to administering a system (e.g., looking at what users are configured, and reading logs) usually don't require
Also, just as potentially a malicious program could watch what someone types when they run
su, or create a fake
su password prompt, potentially a malicious program could create a fake login screen, too.
What makes a user an administrator?
In Ubuntu 12.04 and later, administrators are members of the group called
In Ubuntu 11.10 and earlier, administrators are members of the group called
When an Ubuntu system before 12.04 is upgraded to 12.04 or later, the
admin group is kept for backward compatibility (and continues to confer administrative power to users in it), but the
sudo group is used as well.
Limited User Accounts
Can I use a limited user account instead of an administrator account?
If you like, sure. Create a limited user account in System Settings > User Accounts, and log in as that user.
Can I make my administrator account a limited user account?
Yes, just remove it from the
admin groups (see above).
But you should make sure there is at least one other administrator account, so you can administer your system. If there is not, then you'd have to boot to recovery mode or a live CD and make some user an administrator again. (This is similar to resetting a lost administrator password.)
Graphical tools for administering users and groups will usually keep you from creating a system with no administrators, or at least warn you. Command line tools typically will not (trusting that you know what you're doing).