It would be remiss of me as a Linux user and Discourse moderator not to make the following comments.
running as root is not recommended, in fact it is very dangerous and can cause system instability, file corruption and more. If you decide to take those risks, know you are on your own. We will not provide support for users who willingly ran applications/commands as root despite being aware of those risks.
there is a very good reason the root account is locked on Ubuntu; your safety and security as a user. We have sudo…and for almost all users this is more than sufficient.
Slightly off-topic: I recently experimented with both Debian and Arch installs. During installation there is an option to enable the root account. But…you can also skip this section and just create a regular user with sudo privileges.
I firmly believe this is the correct course of action.
Thank you, @rubi1200, for rightfully pointing out that there are risks in performing actions directly as root.
However, it is also true that, for experienced SysAdmins (NEVER a novice user), there are scenarios where there is a need to perform tasks directly as root when the various priviledge escalation systems have not been configured/tuned to allow a specialized task, that needs to be added to a scheduled jobs list, to ensure those priviledges have been correctly coded/configured.
That can only be performed in a test environment where those privileges have been fully granted, then “shaved off” with the proper changes to the system configurations.
Regarding the mention specific to GUIs, dconf-editoris a GUI and needs root to actually function and be useful. Are you suggesting that it is inappropriate? that we should abandon that and restrict ourselves to simply using the gsettings method? From my standpoint, that is a no-go.
Just to clarify, it seemed like a reasonable support request to me.
Is it deemed not a support request because it is specific to functionality related to modules/libraries which are imported from upstream? as opposed to functionality coded/packaged/delivered by Canonical/Ubuntu?
As I said, trying to understand where the line is drawn.
The admonishment for applying root permissions in the gui - IF - files in /home are touched - then root permissions are inherited in the directory at large. Upon reboot the normal user looses all access to the /home directory!
Completely understood, and your described context is very valid!
I only open dconf-editor from a terminal that has been opened as root using pkexec, for that very reason. Never from my regular user account!
As I’ve stated in other postings, it is all a matter of long, matured experience applying a disciplined approach, precisely to avoid the “shoot yourself in the foot” scenario.
I have also dabbled with both Arch and Debian and have always used sudo, apart from the very first install of Debian, when I did not understand how su differed from sudo. It felt too clunky for me to go without sudo which I had learned to use on Ubuntu and thus when I install Arch or Arch-based distro I always go with sudo.
I think what @rubi1200 posted is something especially someone who has never used Linux and decides to make a leap should remember. And to be frank I think it’s something all of us should.
I also agree with @ericmarceau that there are situations for EXPERIENCED user to have full root access and then “going full root” is completely reasonable thing to do.
An experienced user who knows what they are doing, and how to recover if they slip up, can knowingly do things as root when the situation calls for it. They understand the risk & (should) remember to exit root before doing other normal things. I also agree this is not the average user.
I often prefer to type sudo each time myself when doing things that require elevated privileges. When I was new, I think it helped me understand permissions better, what sudo does, and when I needed it and when I didn’t. Probably a good training tool to not become root.
Do yourself a favour and don’t run interactive graphical tools using sudo. Depending on the program you can end up with your configuration for this program getting overwritten with a file owned by root.
For editors you can instead set and export one of the variables SUDO_EDITOR, VISUAL or EDITOR and then use sudoedit file_to_edit or sudo -e file_to_edit. This makes a working copy of the file, runs the editor as your normal user on the copy and writes the copy back if it was changed by the editor.
Please always add a warning to these types of posts because new users a lot of times will just do a search and now with AI they are more likely then ever and may never create an account and I can tell you from being on the Ubuntu forums and here for more then 18 years in total new users just copy and paste commands and never give a second thought about it until their system is broken.
When you are creating posts you always have to write your posts for the total new user because the more experienced users who will understand the risks are probably not the ones coming here for help most of the time because they don’t need it.
I’m an experienced Linux user. On other distros, I’ve used su for a terminal session with a root account. I realize sudo is a security precaution. I have a phone based on Ubuntu, and tapping ‘sudo’ at each command is a pain with the OSK. I now see that sudo itself provides a workaround. I intend to use that.
I think it’s the nice -n -19 part. Because that DOES put that process at a higher priority than others, even a root prompt. If something ends up eating all your CPU it will cause instability. I think peter is attempting to point out that “if you do this you need to be REALLY CAREFUL to not run things that’ll eat all your resources if you run the wrong command or script in that terminal”.
I preface this with a warning that my way of doing things is definitely not suitable for novice users.
As a long-time user of linux since 1997, I always create the root user account and just use the root account for everything. I use a wrt router with my own rules and ensure my firewall is fired up with my own rules.
Using a subservient account for everything breaks so many things in my setup. I keep regular backups so if I do break anything it’s only a couple of clicks away from recovery.
The most annoying thing about a normal user account is when you have to use sudo or su to achieve something and all of a sudden the screen fonts reduce to a tiny fraction of normal and is impossible to read. This is because I use HDMI to my 55” tv with all my computers in the loft via an HTPC amplifier setup.
Life is so much easier when you are in total control of your own system.
For a very long time, Barfly, I was fully behind that stance!
However, grudgingly, I have come to recognize, accept and respect the need for a separate regular account, for when truly venturing … “where no one (specifically me) has gone before!”
I don’t like the practice of imposed sandboxing by the use of a virtualized environment, but the “safety net” of a regular user does offer the degree of peace of mind that allows me to try things that are on the edge of a precipice, where it could go either way because I couldn’t get enough information before trying … but need to move forward.
My “rooted” terminal session is intended almost exclusively for availability in case of need for a “reign-in” intervention. The other stuff is just standard, well-known utilities with known outputs, like lsmod, lsusb, ifconfig/ifdown/ifup.
Then maybe you shouldn’t claim that sudo is “redundant”.
Otherwise your future experience might include some “war stories” from when you did something silly, like rm -rf / in a root terminal; or dd if=/path/to/destination of=/path/to/source – every single actually experienced user has one of those, even if they don’t admit it.
Always remember the abundance of rope afforded even (or especially?) to inexperienced users.
And you are assuming right, but running them without sudo first, you’d still have a second chance of realizing your mistake. Plus, as I said in my first comment to this topic, the “redundant” sudo in front serves as an extra reminder that one is treading on dangerous ground with virtually zero safety precautions. It is rather easy to forget that you are in a root shell, if you even had the foresight to make your prompt warn you ($ vs #).
Plus, the saying goes that smart people learn from their own mistake but geniuses learn from other people’s mistakes too. Consider the Ubuntu way of requiring sudo as you learning from other people’s mistakes.
What people on here are forgetting, is the best way to learn is by making mistakes. The way people on here are so enthused with preaching their own viewpoints on whether to enable the root account or not, they are totally losing the fact that it is the owner’s prerogative to do whatever they like with their own gear. If they want to take chances with their own setup - then so be it, it is only through doing this sort of experiment that newcomers learn, just as we all did.
You cannot insulate people from their own recklessness, all you can do is try to influence and guide them, point out the pitfalls and let them make their own mistakes.
Maybe instead of banging on about how bad the root account is, they should concentrate more on banging on about the need for constantly updated backups of their system so they can recover and learn from their bad experiences. I think this would be far more productive…
