How is root access managed in Ubuntu?
👁️ 7 views💬 4 replies❤️ 0 likes
4 Replies
Recently, while trying to install Docker on Ubuntu 22.04 for a project, I ran into a "permission denied" error. To make the Docker socket accessible without root, I manually edited the `/etc/sudoers` file, but then I couldn’t run some basic commands on the system anymore. I quickly booted into recovery mode from a live USB and restored the sudoers backup—hopefully you’ve done the same, because everyone makes that mistake at least once. Since then, I’ve been more careful about checking what a command actually does before running it with sudo.
As for persistent root access, when I need to access the root directory, I prefer using `sudo -i` or `sudo su -`. I also avoid just `sudo su` because the latter doesn’t pull environment variables from the root profile, which can sometimes break built-in commands. And one more thing—editing the sudoers file with `visudo` is way safer than manual edits, so I’d recommend that to everyone.
When comparing Ubuntu to Windows Server, we see significant differences in root access management. While Windows encourages persistent high-privilege use with "Run as Administrator," Ubuntu emphasizes using sudo minimally and controllably. Limiting privileges is important for security in both systems, but it's especially critical in Ubuntu because the root account is disabled by default—similar to disabling the Built-in Administrator account in Windows.
Just as you wouldn’t constantly run commands as administrator in Windows, you shouldn’t routinely execute root commands in Ubuntu. Instead, just like launching a task with admin rights only when necessary in Windows, you should use sudo in Ubuntu only for specific commands and avoid keeping a root terminal open indefinitely. For persistent root access—rather than creating a constantly active root account like Windows' local admin—it’s unnecessary. Instead, properly configuring the sudoers file to grant permissions only to the necessary users and commands is much safer. The same mistake made in minimal systems like ttylinux can happen in Ubuntu: keeping the root account persistently active poses serious security risks.
If you're old school, you can manually mess with `/etc/passwd` and `/etc/shadow`, but Ubuntu now defaults to installing the `sudo` system after root's password gets dumped in the shadow password file. The behind-the-scenes of sudo has some interesting details: commands are parsed from config files like `/etc/sudoers` and `/etc/sudoers.d/*`, the default timeout is 15 minutes, but you can set it to indefinite with `timestamp_timeout=-1` (don't ever do this). Sudo also has bash-completion, so when you type `sudo apt update && sudo<tab>`, it auto-completes the command for you.
When it comes to security, using `sudo bash` instead of `sudo -s` keeps you safe from PATH manipulation and makes file paths more robust. Also, in a default Ubuntu install, the `sudo` group is enabled, and anyone in that group can use root privileges. If you want permanent root access, open `/etc/sudoers.d/custom-root`, add the line `root ALL=(ALL:ALL) NOPASSWD:ALL`, but this requires reducing the user count to one and setting up a fully isolated environment.
Alright, so here's the scenario: You're a system administrator and need to perform bulk operations on sensitive data within the file system. How efficient is managing root access by using *sudo* for every command instead of *sudo -i*? Especially in long-running scenarios, how do you minimize risks like commands not being logged in history or accidentally opening a shell with *sudo* into a directory where it shouldn't be? I usually prefer using *sudo* per process, but what are the pros and cons of using *sudo -i* or *sudo su* in automated scripts?