As I said in my comment above about
sudo -s, it will still write files as root ownership, which can break things, for example when installing with Apt.
In older and-or more commercial distros than debian-based Ubunutu, they used a Wheel group that gave those users sudo priveleges. In Ubuntu, the group is called Admin. So add the user to that group with
usermod -aG username admin and also to the sudo group with a similar command. The system won't require adding sudo to everything and will keep file permissions intact.
For the Apt package manager, which insists on using sudo, and which can cause large problems when installing packages as root, just use an alias
Put that in your .bashrc file with
echo "alias apt='sudo apt'" >> .bashrc and then reload it with
You can also add this line to /etc/sudoers using visudo to stop from having to enter your password for sudo commands
username ALL=(ALL) NOPASSWD:ALL
BE AWARE: this does make your system less secure. But for a home system, it is a tradeoff for productivity. Probably best to use a strong password (though files can still be accessed from another OS, even root password can be changed), so that only buys one time if a physical access is compromised. Good firewall protections are important to limit external access to a few ports by need only. GUFW by default has deny all incoming. Another trick is to use a Yubikey and change the first slot to be a long random password entered by USB with a touch. And also keep sensitive personal data in an encrypted volume like with Veracrypt that will save and dismount automatically if power is cut. The you're really only worried about a targeted persistent attack, which I'm not sure how much enforcing sudo really helps. It seems to be more for standard business permissions and to let users know they are about to possible alter their main system.
EDIT: this still requires sudo for certain things like visudo and some root /usr/bin commands like shutdown. The advice in the linked answer was to use an alias that includes the sudo: https://unix.stackexchange.com/a/584507/346155
EDIT2: I also really like the idea of either changing the timeout to longer than 60 seconds or running a while loop to stay validated (that would reset on restart or exit of shell). I think this comes up most often in the setup phase of an OS/desktop-env/package or group of packages for a project. Once setup, there's usually not so many requests for sudo in a given session. Both here: https://stackoverflow.com/a/58933663/4240654
while true; do sudo -v; sleep 60; done (v for --validate)
echo "alias sudov='while true; do sudo -v; sleep 60; done; &' >> ~/.bashrc
visudo then add
Defaults timestamp_timeout=360 #minutes. This works also:
echo 'Defaults timestamp_timeout=360 #minutes' | sudo EDITOR='tee -a' visudo
EDIT3: A problem is that even as after adding a user to the sudo group, they still have to type
sudo for things like
cat /etc/shadow. This is because
ls -l /etc/shadow shows ownership of root or shadow group. I'll have to keep looking for other exceptions. Ideally, adding a user to sudo with a longer timeout should be a good solution. ..I see, I just need to also add the user to the root group and this should solve the problems I've run into with root owned files. Yay, I hope that's solved now!
sudo usermod -aG root user
EDIT4: I found a few more problems described here (https://askubuntu.com/questions/1385695/usermod-cannot-lock-etc-passwd-but-user-is-in-root-group-which-owns-file), but even though I cant
sudo -i anymore, I can apparently
sudo -s still. This is with root having nologin, but the user root still shows up in the cli prompt. Hmm, I wonder what this does to root's .bashrc, etc.