You are a DevOps engineer working on a critical project with a deadline of a month from today. It is 7.30 am, and you put your alarm on to snooze for 10 minutes. Don’t we all love the precious extra minutes we get in bed in the mornings? Unfortunately, your mind has other plans and happily reminds you of the priority actions in your backlog to be completed today. Forget the sleep! You are out of your bed the next instant and checking your Slack messages. Such a relief when there are no urgent issues to tackle…

Cut to your desk at the office: You sit down after a piping hot cup of coffee (or tea). You log in and follow your routine –

• Refresh emails and check/respond to the priority emails (who has time to write or pull content for marketing materials? Not a priority, and no reply for now)
• Respond to Slack messages
• Pull up your to-do list (why are the two priority tasks that woke you up not on the list?)
• A quick check of your favorite news sites (there better not be another headline on fuel price hikes!)

You move onto other tasks for the day — migrating workloads, restarting a container, monitoring project health… You need to modify access rights for some users and log in as root with the su command.

You want to delete some folders while you are at it. You type the command for deleting folders: rm -rf /. You hit enter before you realize what you are doing.

Your heart stops for a painful and shocking moment.

Did you just do the unthinkable? You refuse to believe you could have been so casual. You start to sweat while you check, but there is no doubt about it. You did. You just deleted everything! How?

Your colleague sees your face and steps up to you. You quickly explain to her what just happened. You don’t listen to her comments as you realize the amount of work to be repeated now. You swallow the lump in your throat and rush to your manager.

Two hours later…

They were the worst two hours of your life. No, waiting for your exam results or a job offer pale compared to the agony of being responsible for deleting everything in the system. The senior leaders are in the office, talking to the client team and letting them know about the setback. The estimate is a delay of six months for the project delivery.

Six months! You are in shock.

The CTO of your company sits down next to you. You prepare yourself mentally for a lecture you never wanted.

“By now, you know running as root has its side effects that are irreparable and disastrous, as you found out today. You should know these key reasons to avoid invoking root for inessential tasks, so you are more cautious in future.”

Prompt before running the command

One way to avoid damage is if you had an “are you sure?” pop up on the screen to remind you to check the command. (If only that had happened today!) This prompt does not appear in the root.

Non-traceability

On server machines or when multiple systems and administrators who need root privileges are involved, identifying the user who took the damaging actions and rectifying them is impossible when you log in as root.

Minimize risk of damage from accidents

When you browse as the root, you are more vulnerable to malicious material downloaded on your system. Running programs as root when not required causes unwanted results due to potentially harmful bugs.

Logging in graphically

A graphical interface requires many applications in the backend to run efficiently. By logging in graphically as root, you increase the number of applications needed. Root access is not ideal for running unnecessary programs that may have bugs. Graphical applications are not tested or supported well in root.

“Did you know there is an alternative to root?”

It is the sudo command. Sudo allows you to think about the commands you give and what will happen once executed. It further helps protect us from damage by its ability to restrict access to select commands. Using the config file, a user can be allocated root access to a set of commands. This access avoids common problems with complete access that the root allows.

As much as possible, perform administrative tasks from a user account and only invoke sudo when superuser privileges are required. If you need to run an application as root, use gksudo or sudo -H commands, which use fewer programs than logging into the root account graphically.

And the lesson that stayed most with me is this…

Knowing the pros and cons of anything, be it a command or an operating system, is essential to understanding how it works and how not to use it. Having a root account doesn’t make your system insecure. The actions performed out of carelessness as root or giving unnecessary root access to users make it dangerous.

While this may or may not have happened in real life, any resemblance to DevOps engineers you know is purely coincidental and completely unintentional.

Follow our LinkedIn Page. To explore our services, visit our website.

https://www.redhat.com/sysadmin/difference-between-sudo-su

https://askubuntu.com/questions/16178/why-is-it-bad-to-log-in-as-root