I've often come across posts on forums or other websites where you see people joking in such a manner about running/logging in as root as if it's something awful and everyone ought to know about it. However, there isn't much that a search reveals on the matter.

It may be widely known to Linux experts, but I really don't know why. I remember always running as root when I first tried Linux years ago (Redhat and Mandrake) and don't remember running into any problems because of that.

There are actually some distros that have a bright red background with alert signs all over it as wallpaper for the root user (SuSe?). I still use the "Administrator" account for regular use on my Windows installation and haven't ever run into any problems there either.

  • 18
    I think there is no problem in running a program as root. Its just that, you might harm the core of your OS (even sudoers can do that) if you aren't much wise in linux. other than that I don't thing there is any problem. But that's just my point of view. Dec 4, 2010 at 17:09
  • 1
    Related question here.
    – loevborg
    Dec 4, 2010 at 17:54
  • The difficulty of getting into root mode varies between distros. I personally am annoyed by how Fedora doesn't allow you to 'sudo' right out of the box. OpenSUSE and Ubunto do have pre-configured sudo though... and so if you choose the right distro, you can minimize your annoyances at not being able to get access to files.
    – djangofan
    Mar 28, 2011 at 21:13
  • 4
    @GauravButola even if you're an expert, it's still a bad idea in case an application gets compromised.
    – strugee
    May 12, 2013 at 10:59
  • 3
    @DaboRoss the OP comments that he works in windows as administrator; for my (little) experience in that OS, it seems to me that it is more like Ubuntu: it is a privileged account in the sense it can do whatever you want, but it asks for permission before for example installing new software. So probably the equivalent of using user "administrator" in windows translated to Ubuntu would be to run the main user with sudo configured so that it doesn't ask the pass --- running directly as root is much more dangerous.
    – Rmano
    Jan 21, 2014 at 15:20

22 Answers 22


It defeats the security model that's been in place for years. Applications are meant to be run with non-administrative security (or as mere mortals) so you have to elevate their privileges to modify the underlying system. For example, you wouldn't want that recent crash of Rhythmbox to wipe out your entire /usr directory due to a bug. Or that vulnerability that was just posted in ProFTPD to allow an attacker to gain a ROOT shell.

It's just good practice on any operating system to run your applications on a user level and leave administrative tasks to the root user, and only on a per-need basis.

  • 9
    ...and it protects you from transforming trivial errors in disasters. I am an Unix user/adm since 1990, but still I can surely slip a space in the exact wrong place doing a rm -rf tmp/tests/*...
    – Rmano
    Jan 20, 2014 at 22:50
  • 17
    1.) Most people will consider their home directory as more important than root dirs, for the former cannot be re-installed. So I don't see your point. 2.) In terms of security, you are right. But coming from windows (where there is WAY more malware around), where I've used the admin account since ever (as many do), I have a hard time considering this a real danger. I am just too lazy to type sudo and my password for every second command in Linux. Aren't Linux users supposed to be lazy?????
    – phil294
    Mar 9, 2016 at 0:46
  • disagree -_- :~ :|
    – Edgy1
    Sep 25, 2016 at 2:48
  • 1
    That's a good call out @Blauhirn. I just sent in a follow-up edit to reflect we don't want it deleting the entirety of /usr. In terms of protecting your $HOME folders, nothing like a good backup can help you. I don't think this particular scenario would be related to security as much as good practice. Thanks again for the callout.
    – lazyPower
    Jun 12, 2017 at 16:30
  • 2
    @Pryftan ...Yes, we can encrypt /home, put it on different volumes, blabla. This is not about individual steps, it is about the obligatory need to protect admin data but ignore snoops on home data. Finally, no, any one who is lazy when working at a computer is asking for trouble I disagree. Yes, you need to make backups. You should also deeply care for your security. But laziness can lead to great innovation. I automize many things in bash scripts because Im too lazy to type them in 10 times in a row. Is that a bad thing?
    – phil294
    Feb 21, 2018 at 20:28

Just one word: security.

  1. You're logged as root = all applications are running with root privilegies -- every vulnerability in Firefox, Flash, OpenOffice etc. now can destroy your system, because possible viruses now have access everywhere. Yes, there are only few viruses for Ubuntu/Linux, but it's also because of good security and default unprivileged user.
  2. It's not only about viruses -- small bug in an application could erase some system files or...
  3. When your're logged as root, you can do everything -- the system won't ask! Do you want to format this disk? Ok, just one click and it's done, because you're root and you know what you're doing...
  • 25
    Data files, which are all owned by my user account, are much more valuable to me than system files. All of your above examples are still issues when logged in as a user, except that the easily-replacable system files are safeguarded.
    – kbeta
    Apr 29, 2013 at 21:02
  • 8
    @kbeta you're assuming that you're running on a computer where the only valuables are your data and system files. In reality linux is often used in a system where there are many users using a system simultaneously. In this case the stability of the system (and therefore the system files) is far more valuable and other user files are important too. Feb 28, 2017 at 15:11
  • 2
    @kbeta Fair enough but a damaged system configuration can also pose a risk to your data... and of course having backups would be a good idea whether your system is at risk currently or not. Working current backup with a disaster recovery plan would be better yet.
    – Pryftan
    Feb 21, 2018 at 20:14
  • so it means that an application should never be launche this way? : sudo myApp.py because it would be the same as rurring it from root?
    – Heetola
    Feb 24, 2020 at 12:28

Running as root is bad because:

  1. Stupidity: Nothing prevents you from doing something stupid. If you try to change the system in anyway that could be harmful you need to do sudo which pretty much guarantees a pause while you are entering the password for you to realize that you are about to make a possible big/costly change.
  2. Security: It has been mentioned already quite a few times in this question but basically it's the same thing, harder to hack if you dont know the admin user's login account. root means you already have one half of the working set of admin credentials.
  3. You don't really need it: If you need to run several commands as root and you are annoyed by having to enter your password several times when sudo has expired all you need to do is sudo -i and you are now root. Want to run some commands using pipes? Then use sudo sh -c "comand1 | command2".
  4. You can always use it in the recovery console: The recovery console allows you to try and recover from doing something stupid or fixing a problem caused by an app (which you still had to run as sudo :)) Ubuntu doesn't have a password for the root account in this case but you can search online for changing that, this will make it harder for anyone that has physical access to your box to be able to do harm.

The reason why you couldn't find information about why it's bad is because, well, there is way too much data in the internet :) and that a lot of people that have been using Linux for a long time think like you do. This way of thinking about the root account is fairly new (a decade maybe?) and a lot of people still get annoyed by having to use sudo. Especially if they are working on a server which means they went in with the intention to make system changes. Probably brought on from previous bad experiences and security standards most sysadmins know better but they still don't like it :).

  • 'a decade maybe?' Much much longer than that even from when you wrote this. Even without sudo there is su not to mention e.g. the wheel group (for example). Privilege separation is always important and always has been important and always will be important. Otoh not as many people used Unix based OS that many years ago and many who do are used to always being an administrator.
    – Pryftan
    Feb 21, 2018 at 20:44
  • 3. You don't really need it (because you can do it via the command line) – Just that doing it via the command line usually is slow and unhandy, and doing it via the GUI is quick and smooth. Aug 3, 2023 at 15:56
  • Privilege separation is always important and always has been important and always will be important I am sitting on a private laptop. I am the only user. Why would I need privilege separation? Aug 3, 2023 at 16:44

This is a good question. I think the answer is slightly different depending on whether you're talking about a server or a desktop installation.

On a desktop, it is uncommon to use the root account. In fact, Ubuntu ships with root access disabled. All changes requiring superuser privileges are done through sudo and its graphical cognates gksudo and kdesudo. Given that it's easy to set a root password, however, why don't people do it?

One reason is that it gives you an additional layer of security. If you run a program as root and a security flaw is exploited, the attacker has access to all data and can directly control the hardware. For example, it might install a trojan or key-logger into your kernel. In practice, though, an attack can do a large amount of damage even without superuser privileges. After all, all user data - including documents and stored passwords - is accessible without root access.

A more valid point, on a single-user system, is that the user is prevented from accidentally rendering the system unusable. If the user unintentionally issues a command that deletes all files, they will still be able to boot the system, even if the data is lost.

Additionally, most user-facing (X11) applications today are built on the assumption that they're run as a regular user account and without administrator rights. Thus some programs might misbehave when run as root.

On a multi-user system with non-graphical shell access only, many of these reasons do not apply. However, Ubuntu still reasonably defaults to an inaccessible root account. For one thing, there is a real difference between gaining access to a user account (with sudo rights) through a security hole and gaining access to root, as in the first case disrupting other users will require running sudo and will still prompt for the account password as an additional security step. For another, it is useful to perform many administrative tasks from a user account and only invoking sudo when the superuser privileges are absolutely required. Thus when installing a program from source, it is advisable to build the source - running configure and make - inside the user's directory and only using sudo make install in the final step. Again this makes it more difficult to shoot oneself (and other users of the multi-user system) in the foot, and it decreases the likelihood of build scripts wreaking havoc with the system. Thus even on a server it is good advice to stick to Ubuntu's sudo-based administration.

  • 4
    he will still be able to boot the system, even if the data will be lost. - What's the point of this? If my data is lost, my data is lost and that's it. Linux system software can be reinstalled if deleted, why should I care about data loss in such diretories? On the other hand, data loss in ~ is bad. And sudo doesn't protect me from that.
    – phil294
    Mar 9, 2016 at 0:52
  • 3
    Another good practice is to have important data backed up. If you wipe out home directory, you could still boot and just copy over files from the backup. Or, let's say you have a small laptop for travel. It might have some pics, travel notes, train schedule - but nothing too crucial. If you wipe the user files, you can still boot the system up and check in for your flight or find out which bus to take.
    – Richlv
    Jan 7, 2018 at 0:21
  • @Blauhirn Backups. And there is a chance of recovery even if it looks bleak.
    – Pryftan
    Feb 21, 2018 at 20:15

One reason not to run as root that has not (so far) been identified by other answers is traceability. It probably matters less on machines that are primarily single-user machines (your desktop or laptop), but on server machines, if someone is logged in as root, you don't know who to blame for the actions taken. Therefore, most professional organizations with multiple systems and multiple administrators that need root privileges require people to login using their own user ID (and password), and then use sudo or similar programs to operate with root privileges when necessary.

Otherwise, the primary reasons for not running as root are:

  • Minimize risk of damage from accidents. If you run rm -fr / home/me/my-subdir as root, then you've just dramatically eliminated everything of importance from your machine because of that space after the (first) slash - because the stuff that goes first is the stuff that was added first - little things like the kernel, the /bin and the /etc directory. Unix gets upset if you lose those.

  • Minimize risk of damage from malicious outside sites. If you browse as root, you're more nearly vulnerable to drive-by downloads of malicious material.

I use MacOS X more than I do Ubuntu, but there, root is disabled by default, and it still is on my machine. I routinely upgrade the kernel and other similar operations - using sudo (behind the scenes). Similar techniques apply to Linux generally.

Basically, you should only use the all-powerful privileges of root for abbreviated periods of work to avoid the risk of mistakes.

  • 2
    It is not about blaming someone, it is about being able to figure out why someone made a change.
    – jippie
    Apr 17, 2012 at 21:18
  • 3
    @jippie: I mean 'blame' in the same way that a VCS tracks who did what so that the correct person is attributed with the responsibility for the change, for good or bad, and one of the names for the command that does that tracking is 'blame'. It gives you a person to speak to to find out why something happened. It is not always 'fault' (though depressingly often, the reason for needing to know is because something isn't quite working as expected and there's a need to know why not). So, it is about accountability and trackability rather than necessarily faulting the person for what they did. Apr 17, 2012 at 21:44
  • 1
    On Ubuntu, commands like rm -fr / home/me/my-subdir do not actually attempt to recursively delete /, because / is treated specially to guard against such mistakes. See the documentation of the --preserve-root and --no-preserve-root options in man rm for details. But the principle is sound: single-character typos do exist that result in rm deleting everything. For example, if you mean to remove everything in the current directory by running rm -r *, but you accidentally put a / before *, that would be bad. May 3, 2015 at 17:18
  • @EliahKagan But yet if you were to do... chown -R nobody:nobody ../ from say /etc would it protect you? If you were to do that on /etc it would cause you a world of hurt. Similarly is .* when recursively running a command.
    – Pryftan
    Feb 21, 2018 at 20:48

TL;DR: Do things as root only when you have to. sudo makes this pretty easy. If you enable root logins, you can still follow this rule, you just have to be careful to do so. Although enabling root logins is not actually insecure if done right, you don't need to enable root logins because you have sudo.

There are really two related questions here.

  • Why is it bad to to log in as root for one's everyday computer use (web browsing, email, word processing, gaming, etc.)?
  • Why does Ubuntu default to disabling root logins altogether and using sudo and polkit to enable administrators to run specific commands as root?

Why not run everything as root, all the time?

Most of the other answers cover this. It comes down to:

  1. If you use root powers for tasks that don't require them, and you end up doing something you didn't mean to do, you could change or harm your system in a way you don't want.
  2. If you run a program as root when you didn't need to, and it ends up doing something you didn't mean for it to do--for example, due to a security vulnerability or other bug--it could change or harm your system in a way you don't want.

It's true that even without doing things as root, you can cause harm. For example, you can delete all the files in your own home directory, which usually includes all your documents, without running as root! (Hopefully you have backups.)

Of course, as root, there are additional ways to accidentally destroy those same data. For example, you could specify the wrong of= argument to a dd command and write raw data over your files (which makes them way, way harder to recover than if you'd merely deleted them).

If you're the only person who uses your computer, the harm you can do only as root might not really be higher than the harm you can do with your regular user privileges. But that is still no reason to expand your risk to include additional ways of messing up your Ubuntu system.

If running with a non-root user account prevented you from exercising control over your own computer, then this would of course be a bad tradeoff. But it doesn't--anytime you actually wish to perform an action as root, you can do so with sudo and other methods.

Why not make it possible to log in as root?

The idea that the ability to log in as root is inherently insecure is a myth. Some systems have a root account enabled by default; other systems use sudo by default, and some are configured with both.

  • For example, OpenBSD, which is widely and reasonably considered the most secure general-purpose OS in the world, ships with the root account enabled for local, password-based login.
  • Other well-respected OSes that do this include RHEL, CentOS, and Fedora.
  • Debian (from which Ubuntu derives) has the user decide which approach will be configured, during system installation.

It's not objectively wrong to have a system where the root account is enabled, provided that

  1. you still only use it when you really need to, and
  2. you restrict access to it appropriately.

Often novices ask how to enable the root account in Ubuntu. We should not conceal this information from them, but usually when people ask this it's because they are under the mistaken impression that they need to enable the root account. In fact, this is almost never necessary, so when answering such questions it's important we explain that. Enabling the root account also makes it easy to become complacent and perform actions as root that don't require root privileges. But this doesn't mean enabling the root account is by itself insecure.

sudo encourages and helps users run commands as root only when they need to. To run a command as root, type sudo, a space, and then the command. This is very convenient, and many users of all skill levels prefer this approach.

In short, you don't need to enable root logins because you have sudo. But so long as you use it only for administrative tasks that require it, it's about equally secure to enable and log on as root, so long as it's only in these ways:

  • Locally, from a non-graphical virtual console.
  • With the su command, when logged in from another account.

However, substantial added security risks arise if you log on as root in these ways:

  • Graphically. When you log in graphically, a whole lot of stuff runs to provide the graphical interface, and you'll end up running even more applications as root to use that interface for anything. This goes against the principle of only running programs as root that really need root privileges. Some of these programs may contain bugs, including security bugs.

    Furthermore, there's a non-security reason to avoid this. Logging in graphically as root is not well supported--as loevborg mentions, developers of desktop environments and of graphical apps don't often test them as root. Even if they do, logging in to a graphical desktop environment as root doesn't get real world alpha and beta testing by users, as almost nobody attempts it (for the security reasons explained above).

    If you need to run a specific graphical application as root, you can use gksudo or sudo -H. This runs far fewer programs as root than if you actually logged on graphically with the root account.

  • Remotely. The root account can in effect do anything, and it has the same name on practically every Unix-like system. By logging in as root via ssh or other remote mechanisms, or even by configuring remote services to allow it, you make it much easier for intruders, including automated scripts and malware running on botnets, to gain access through brute force, dictionary attacks (and possibly some security bugs).

    Arguably the risk is not extremely high if you allow only key-based, and not password-based root logins.

By default in Ubuntu, neither graphical root logins nor remote logins via SSH are enabled, even if you enable logging in as root. That is, even if you enable root login, it's still only enabled in ways that are reasonably secure.

  • If you run an ssh server on Ubuntu and have not changed /etc/sshd/ssh_config, it will contain the line PermitRootLogin without-password. This disables password-based root login, but allows key-based login. However, no key is configured by default, so unless you've set one up, that too will not work. Furthermore, key-based remote root login is far less bad than password-based remote root login, in part because it doesn't create the risk of brute force and dictionary attacks.
  • Even though the defaults should protect you, I think it's still a good idea to check your ssh configuration, if you're going to enable the root account. And if you're running other services that provide remote login, like ftp, you should check them, too.

In conclusion:

  • Do stuff as root only when you need to; sudo helps you do that, while still giving you the full power of root anytime you want it.
  • If you understand how root works and the dangers of overusing it, enabling the root account is not really problematic from a security perspective.
  • But if you understand that, you also know that you almost certainly don't need to enable the root account.

For more information about root and sudo, including some additional benefits of sudo that I haven't covered here, I highly recommend RootSudo in the Ubuntu help wiki.

  • 'If you're the only person who uses your computer, the harm you can do only as root might not really be higher than the harm you can do with your regular user privileges. But that is still no reason to expand your risk' Not to mention it puts you in the habit of it... then you go to another system and what happens? Same with the absurd idea of making people get used to rm -i by way of shell alias. You go to a system that doesn't have that and then what? Baby sitting a user from mistakes like this is never a good idea when you consider humans are very much creatures of habit.
    – Pryftan
    Feb 21, 2018 at 20:51
  • Brilliant answer. Best I've seen. Thanks so much for explaining it so well for Linux noobs like me. Dec 16, 2019 at 6:23

Root account is disabled by default - meaning that it exists but it's not usable (except in recovery mode). This means that an attacker is aware of your root account, but couldn't use it even if he/she had the root password. Thus, an attacker has to guess both a user-name which has administrator privileges, AND that user's password (which is far more difficult than just trying to work out the root password).In XP if you have the Recovery Console installed, anyone who has physical access to your box can boot into it (RC) - no password required. Same as Recovery Mode in Ubuntu.

In Ubuntu, when they say that the root is disabled - what is really meant is that the account is locked. An account is locked by changing the password to a value which matches no possible encrypted value. This effectively prevents anybody from being able to log in as root - since there would be no possible way they could enter the password. Since there are still times when root access is necessary - the Ubuntu kernel has been modified to allow root local login only in single-user mode.

Also see this page

  • Um. No offense but you might want to read the title of the question and then read the details again.
    – Mussnoon
    Dec 4, 2010 at 17:24
  • 3
    This is extremely helpful - and it does relate to the question. It's concerned with the security implications of enabling the account, a prerequisite of running as root. Dec 4, 2010 at 20:24
  • 1
    @Stefano Palazzo: While the information provided may be useful, I sincerely can't see in what part lies an answer to what I needed to know. I've read it multiple times.
    – Mussnoon
    Dec 5, 2010 at 4:32
  • Doesn't prevent people being able to log into root.
    – Chad
    Sep 19, 2016 at 1:49

Its like arming a little kid with an AK47, while he can happily play with his paintball gun. ;)

I mean its wrong because you and your applications will have more privilege then they need and that is when things can and sometimes will go wrong :(

  • 5
    a more clever analogy.(^_^)
    – kit.yang
    Dec 5, 2010 at 9:36
  • 2
    This is an entirely inappropriate analogy. A child with an AK47 can kill themselves and other people. A unix-user with root access can at most render their system temporarily inoperable. (One can always re-install the os and recover operation).
    – kbeta
    Apr 29, 2013 at 20:54
  • @kbeta You're right, my analogy is a bit out of proportion and exaggerated. please move on.
    – omeid
    May 12, 2013 at 10:49
  • @kbeta the analogy is appropriate. the risk is not an inoperable system, but data and privacy loss. the root user can delete the data. please use your phantasy to associate the killing and data loss.
    – n611x007
    Jan 9, 2016 at 19:12
  • But if there is only one user on the system and that user needs sudo privileges, aren't the privileges/access rights the same as root?
    – Cristy
    Apr 6, 2022 at 12:43

Very nice question... Let me answer it from a practical point of view:

When I started using Linux, which is more than 10 years ago, the major distributions did not advertise using non-root accounts as much as today. As I was used to Windows I also did not see a point in using a constrained user account. In particular because I had to enter "su" very often - sudo wasn't that popular back then. ;-) So I always logged in as root because I had a lot of maintenance to do to get my system well configured. But guess what, any fresh installed system became quickly very unstable.

One concrete problem for instance: I haven't had that much harddisk space reserved for Linux so it happened to me a few times that I had 0 bytes left on my partition. Maybe I'm not completely precise because I don't know the exact mechanism, but when you fill up a disk with a non-root account there are always a few kilobytes left. But if you really have 0 bytes left, your system makes weird errors and you might end up with some hard to fix damage in your system because there is a lot of system software running in the background...

Another thing is: That division between root and non-root keeps your system well-organized. As a root-user you might be tempted to not cleanly install your new applications which leaves you with a dirty, hard maintainable system.

But the good thing: Modern distributions do most of the administration tasks for you, so seldom you have to fiddle in the guts of your Linux system with a root account. Entering a password from time to time is sufficient, the rest is done by the distributor's scripts.

But I doubt that you haven't had issues on your Windows system with that if you used 95 oder 98. (At least I had issues with that...) Because of the lack of a clear separation between Administrator and regular user "traditional" Windows apps assume they can do anything E.g. install Spyware if they feel like it, even without telling you. Microsoft engaged in that issue when releasing Vista. (Effectively implementing a sudo mechanism.) So people got very annoying dialogues saying "You can't do that". For some non-Vista-compliant software you needed some dirty hacks to install it, even as Administrator...

  • 'Maybe I'm not completely precise because I don't know the exact mechanism, but when you fill up a disk with a non-root account there are always a few kilobytes left.' Perhaps you refer to lost+found directory ? If so you can as administrator specify how much to reserve. I want to say the typical default is 5% but I could be wrong and it can be changed. It's quite useful though even if rarely needed. Apparently there is more on it here (I remember it from my years of use): unix.stackexchange.com/questions/18154/…
    – Pryftan
    Feb 21, 2018 at 21:00
  • Apprently it's not limited to ext filesystems: unix.stackexchange.com/questions/7950/…
    – Philip
    Feb 22, 2018 at 14:00
  • Yep. I knew that :) But thanks for adding that too.
    – Pryftan
    Feb 23, 2018 at 16:53

There are a lot of aspects behind this approach. Some of them are:

  • Root is all powerful.
  • In Unix and Unix-like systems, system administration privileges are all or nothing. A user either has root access or not, and root access implies complete control of a machine. If the machine in question is used by more than one person, or root has access to other systems or user files, it is more acceptable to give some users partial root privileges.

  • The root user can hide all of their actions.
  • sudo logs every command run via sudo. Having a record of what's being done with sudo helps us diagnose problems with individual systems/processes and general configuration issues, as well as helping us identify needed improvements.

  • The root password gives you access to any command on a system.
  • Via its config file, sudo can give a user root access for a particular set of commands. This also avoids the "all or nothing" effect, allowing us to give individual users more control over their machines and to help themselves out of common problems.

    here is a good article : http://cf.stanford.edu/policy/root

    • But when you have full sudo, you can sudo su and hide your actions. Nov 27, 2015 at 22:47
    rm /*

    Lets say you have been cleaning out an administrative area. You get tired of password, so you sudo su. You get distracted just for second and forget you cd to /. Then you rm *. I've done it. You can get it all back, but it's a PITA. Oh, and it's descended into /media too!

    • 10
      We always complain about our PC's being too slow, but it is as if they are optimized for running an rm like that as fast as possible.
      – jippie
      Apr 17, 2012 at 21:37
    • 1
      @jippie Because RM just destroys the inode link to the file. Doesn't take long to delete a link and mark a space as "free".
      – Kaz Wolfe
      Jan 20, 2014 at 20:30
    • @jippie, it should have a build in 10 second countdown Mar 4, 2018 at 11:26

    Why not have root login?

    While you can create a password for the superuser account allowing you to log in as root, it's worth mentioning that this isn't the "Ubuntu" way of doing things. Ubuntu have specifically chosen not to give a root login and password by default for a reason. Instead, a default Ubuntu install will use sudo.

    Sudo is an alternative to giving people a root password in order to perform superuser duties. In a default Ubuntu install the person who installed the OS is given "sudo" permission by default.

    Anybody with "sudo" permission may perform something "as a superuser" by pre-pending sudo to their command. For instance, to run apt-get dist-upgrade as a superuser, you could use:

    sudo apt-get dist-upgrade

    Benefits of the sudo approach

    • With sudo, you choose in advance which users have sudo access. There is no need for them to remember a root password, as they use their own password.

    • If you have multiple users, you can revoke one's superuser access just by removing their sudo permission, without needing to change the root password and notify everyone of a new password.

    • You can even choose which commands a user is allowed to perform using sudo and which commands are forbidden for that user.

    • And lastly, if there is a security breach it can in some cases leave a better audit trail showing which user account was compromised.

    Sudo makes it easier to perform a single command with superuser privileges. With a root login, you permanently remain in a superuser shell which must be exited using exit or logout. This can lead to people staying in the superuser shell for longer than necessary just because it's more convenient than logging out and in again later.

    With sudo, you still have the option of opening a permanent (interactive) superuser shell with the command:

    sudo su

    ... and this can still be done without any root password, because sudo gives superuser privileges to the su command.

    And similarly, instead of su - for a login shell you can use sudo su - or even sudo -i.

    However when doing so you just need to be aware that you are acting as a superuser for every command. It's a good security principle not to stay as a superuser for longer than necessary, just to lessen the possibility of accidentally causing some damage to the system (without it, you can only damage files your user owns).

    Just to clarify, you can, if you choose, give the root user a password allowing logins as root, if you specifically want to do things this way instead. I just wanted to let you know about the Ubuntu convention of preferring sudo instead and try and explain some of the reasoning why Ubuntu favors that approach as a default.

    Why not allow root login over SSH?

    Even if your root user does have a password enabling you to log in as root, it is still a good security practice to disable direct root login from outside, such as in SSH. It is reasonable for users to have to su - or sudo after the initial login.

    The potential benefits to this are mostly security-related:

    • It reduces the attack vector by removing the possibility of brute-forcing the root password remotely. It is typical for a server on the internet to be constantly barraged by attempts to brute-force the root password via SSH.

    • It creates a better audit trail so that even in the event of a breach where the attacker does obtain superuser privileges later, you can see whose user account was used to gain access.


    When logged in as root it makes it possible for applications, scripts or commandline commands to access sensitive parts of software which can damage the system. This can be the result of inexperience on the user or programmer's part or due to malicous hidden code.


    It's just too easy mess up when operating as root. You can clobber the entire system in like one command ...


    I can add that there is a difference between Administrator in Windows and root in Unix. Administrator still have some restrictions in systems, where root does not have any restriction. The correct analog of root in Windows is System user.

    The bad thing to use PC under root/System is that you can accidentally destroy anything without any warning from OS.


    Reasons against using root:

    • Could accidentally destroy system files
    • Could get an infection
    • Doesn't log actions

    Reasons FOR using root:

    • Access to everything, no typing passwords
    • GUI, no using terminals for managing system files/directories

    Seems to me that a non-root account could still fall victim of those reasons against using root, the most it adds is a confirmation for your actions. I think that as long as you know what you're doing, you're perfectly safe using root. There, I said it.

    • Although technically there is a way to log actions including every single command. This goes for every user. See process accounting e.g. here: linuxjournal.com/article/6144 And it's only safe truly if you need to be root; otherwise it's not entirely safe (exploit, etc.) even if the command should be safe.
      – Pryftan
      Feb 21, 2018 at 21:07

    If applications are run as root, there is no guarantee that none of them would execute

    rm -rf /

    (This is an example of a command that should not be run.)

    • @StefanoPalazzo This post makes no sense with the command removed, so I've rolled back your edit--you might as well have deleted the post. Note that, contrary to widespread misconception, this command, as written, does not actually delete files when run on an Ubuntu system, but it is similar to commands that do. So if you were concerned someone might unthinkingly copy the command and nuke their system, that is not likely. See the documentation of the --preserve-root and --no-preserve-root options in man rm for details. May 3, 2015 at 15:59
    • Solaris treats this command as undefined behavior according to a wide POSIX interpretation (and Bryan Cantrill) and throws an error Jul 18, 2016 at 15:23

    Given a knowledgeable and careful user, I'm not sure that a right answer exists. I hadn't seen this answer, so I thought I'd chime in.

    What I don't like is unintentional changes of permissions on multi-user systems that I need to chmod later. Fixing via chmod after-the-fact is much more irritating than needing sudo, but it depends on what I have planned.


    There is no danger in logging as root if used carefully.

    Although I think that disabling root is preferable solution, because attacker could not brute force it.

    One solution is to create user in sudo group with obscure name, like gamer and use sudo to perform administrative tasks.

    Hence attacker must not only guess password of that administrative user but his login name too. Which is not obvious if user using sudo has login name like kitty or gamer or something similar.


    Software is based on shared libraries, dependencies, configuration files, etc.
    Most of the times, a single click in an application invokes a "chain reaction" of multiple changes, not only where you think it would probably.
    When these changes are about to affect system-critical settings, it's good for you - as a user - to know.
    That's why root access is a good security model:
    If something crucial is about to happen to your system, you'll be notified by being asked for privilege elevation.


    It's a two-faced problem with more than one answer.

    For some reality check on the ever-same-but-oh-so-awful answers to this:

    desktop installations:

    • use your own user and sudo if need be, otherwise one successfully used attack vector because you don't really know what you're doing and your system is compromised
    • in larger companies chances are, you might not even have root privileges on your own workstation, even if you're an admin, depending on the amount of tin-foil hats being present.

    server installations:

    • there is a vast difference between doing your short work sessions legit as root (provided you have passwordless logins, proper ssh key management for all servers - and fail2ban configured for all password logins while you're at it anyway) and having every daemon/service running with its own user (which is a must) - most people seem to not realize the difference
    • for fun: try using your version-controlled configuration management tools (ansible/puppet/salt/whatever with files from a git server) only without root access. (you do have some form of AAA in place for these special systems, as well as for your monitoring and backup systems, don't you?)
    • also: default rm -rf / doesnt work in most mainstream distros IIRC
    • any serious workplace has a jumphost/bastion-host for accessing the server fleet which logs anything you do anyway, which likely is further protected by 2FA
    • if you have sudo and no jumphost you can fix up the hosts logs to end up however you want them to anyway, if they are not mirrored in realtime, that is.
    • when also the ssh logs are 'cleaned', you can't even be proved to have been on the host, if there is no further network monitoring system in place

    For any company size (read: most likely SOHO with a static ip) in between these two extremes that lacks decent monitoring/backup/automation/logging measures, it may be useful to enforce usage of sudo on servers. (Which gets circumvented by people doing sudo su - ASAP after connecting, letting all your intentions of logging what happened go to waste even without malicious intents as soon as more than one root user is logged in. Good luck changing this through forced procedures and treatening people with draconian measures for failing to obey the rules. Life always finds a way.)

    But if you dont have at least fail2ban to secure your password logins (if there are any present, especially on internet facing systems), plus do mind about proper password handling (password management tools, retention policies, no master passwords, handling these upon employee fluctuations...) and have some form of proper update management for the server fleet in place so all the servers are patched regularily, you likely will be hacked some day anyway, be it from within or from the outside.

    And always having used sudo religiously and having enforced its usage among all people will not change your probability for getting owned much in that case.

    • 1
      Finally a real and differentiated answer, instead of the usual 'never do this'-mantras. +1 and thanks for this.
      – Andreas H.
      Jan 6, 2019 at 15:05
    • +1 upvote on anser and upvote on Andreas H.'s comment. Thank you sjas very much: a down-to-earth answer, which is pragmatic rather than dogmatic. Jun 18, 2020 at 9:46

    Ultimately there is no harm in running as root. It's just a bunch of paranoid people who think that re-installing an OS is impossible. The "Someone might compromise a program.." argument, so what? if they do that then they already could keylog your password, or just display a root password request anyway and have you give them the password. Blow away your system because you select everything in / and delete? oh well, get out the installer and re-install. It takes less than 20 minutes, grab a coffee and chill. Root is fine, I've been running root as long as I can remember and you know what it does? It makes installing packages less of a headache. You don't have to enter root password every 5 minutes like you normally have to. You don't run into problems trying to save/edit system config files because they're root permissions only. It's just so much easier and better to run as root.


    You must log in to answer this question.

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