Home | Catalogue | Robert's Blog
Last Updated: [2023-03-29 Wed 07:59]
How many times have you done this? You’ve logged into a Linux server
and immediately ran sudo su or sudo -s to elevate to the root (*nix’s
equivalent of the Administrator account). Don’t do this, this is bad.
How bad? Well, this Unix horror story (and subsequent legendary
recovery) from the University of Manchester in 1986 is shockingly
relevant today with modern Linux systems: Unix Recovery Legend (Original
Source)
I put the following quote on the company's Slack loading screen a while back which is always a good reminder of what can happen if you’re not careful in the command line.
"Unix will give you enough rope to shoot yourself in the foot. If you didn't think rope would do that, you should have read the man page."
@mhoye, twitter.
So, this page is dedicated to further reasons why this is bad for not only the company you work for, but also your career, as well as alternative solutions.
Any Unix based system has a reputation for being secure thanks in
part to its permissions system. This allows users to be blocks from
seeing other users' files, or being able to only read them but not
write, etc. However, this all goes out the window when using the root
user, as the idea is that root has access to everything. This can be
dangerous when it comes to running commands which can be destructive. In
the example in the introduction, rm * was
run as the root user at the root of the filesystem (/). As the root user owns everything, the
Berkley Unix system happily started to remove everything from the system
starting with the /bin directory.
The other issue is, if a file is created by the root user, then only root has permissions to edit that file. If a program is trying to use that file, it could fail due to insufficient privileges. For example, at my company, we had some software incorrectly running as the root user, it ended up creating new files with the ownership set to root, this caused issues when the application was corrected to use its own user again.
Using just the root account has another problem, and that is finding
out who is logged into a machine at a spesific time. This is also an
issue if users are sharing a user account, though slightly less
dangerous as at least the user account is restricted. However, either
way, it renders tools like last useless,
especially when used in a company that uses a VPN as all connections
would appear to be coming from the same location.
However, enven when each user has their own login, there is still an
issue when sudo su or sudo -s is used as once you use sudo to launch a
root shell, you’re no longer running commands as your user, but instead,
you’re root. Whilst it’s possible to see who has logged into a box at a
specific time, it then becomes a game of matching root’s command history
with the logged-in user by time. If two users are logged in, it then
becomes a mess where commands need picking apart.
When working on files in your home directory, there’s no need to use
sudo at all, if you’re editing a file,
simply launch vim or nano from your own account. Any files created
will then be owned by you.
If you’re making changes to system files or running Puppet, you
should be doing this from your own account by prepending sudo to the
command. For example, running Puppet can be performed from your own
account by running sudo puppet agent -t.
Sometimes, you might have to adjust the command you're using to ensure it works from a regular user account, for example, I have a guide here for Redirecting stdout to a file as a regular user using sudo and tee.
DISCLAIMER: The information provided on this website is generated from my own notes and is provided "as is" and without warranties. Robert Ian Hawdon can not be held responsible for damages caused by following a guide published on this site. This website contains links to other third-party websites. Such links are provided as convienice of the reader. I do not endorce the contents of these third party sites.