Linux compare

Do you sudo? Learn the basics

Logging in as root is easier and quicker, so why use sudo? Nick Hardiman explains.

Sudo

Using sudo is a good idea that has been around for decades, but it’s only in the last few years that it’s caught on as an alternative to logging in as root. Using sudo is such an improvement that some Linux distributions, such as Amazon’s Linux-based VMs, have made it compulsory. Working with AWS has reminded me of the importance of sudo -- and knowing when and how to use it.

Logging in as root is easier and quicker. Why use sudo?

The root account is an explosive

The Linux system treats everything like a file. You can make a file, stick things in it, and delete it. It’s pretty straightforward. The Linux security system is also pretty straightforward -- if you own the file, you can do what you like to it. If you want someone else to do things to the file, you can give them permission to read it, write in it, or even run it (if it is a program).

There’s one person that operates above the law of the security system -- the root user. The master administrator. The super-user. It’s a privileged account -- the root user is the only one allowed to do many useful things, like start a web server, reset a forgotten password, and install security patches.

Anyone can use the root user’s account, if they know the password. If you can log in as root, you can ride roughshod over everyone else’s files. It’s dangerous, but not so much because bad guys will abuse the privilege to spy on users, launch attacks on other systems, and steal data. The big problem with using the root account is that you are only one unfortunate command away from disaster. The longer you work as root, the closer you get to accidentally blowing a big hole in your operating system.

sudo is a stabilizer

The sudo command lets you use the root account to run a command. You can still do the system magic, but you are not permanently playing with the explosive power of root.

Not logging in as root -- like not mixing spots and stripes, not smoking, and not walking around with a gun down your trousers -- is a good idea because it lessens the chance of unpleasant consequences. There is less chance of accidentally stopping a customer service, unmounting critical data, or deleting all the commands.

sudo brings its own set of annoyances

The trouble with sudo is you have to remember to stick it in front of the command you run. Everyone forgets to use sudo from time to time. Sometimes the mistake of forgetting sudo is harmless. You are forbidden from doing your work, but that’s all.

[ec2-user@ip-10-167-15-124 ~]$ yum install httpd

Loaded plugins: priorities, security, update-motd, upgrade-helper

You need to be root to perform this command.

[ec2-user@ip-10-167-15-124 ~]$

Sometimes forgetting sudo is disturbing but still harmless.

[ec2-user@ip-10-167-15-124 ~]$ service httpd status

httpd dead but subsys locked

[ec2-user@ip-10-167-15-124 ~]$

What? HTTPD (the web server) is dead? What about my customer service? And what on earth is subsys? Try it again with sudo and a more reassuring message appears.

[ec2-user@ip-10-167-15-124 ~]$ sudo service httpd status

httpd (pid  1409) is running...

[ec2-user@ip-10-167-15-124 ~]$

sudo su –

A sysadmin often types in many commands that all need root privileges. It’s tempting to just log in as root and do the work. If you are really intent on using the root account, sudo can arrange that. 

[ec2-user@ip-10-167-15-124 ~]$ sudo su -

[root@ip-10-167-15-124 ~]#

The prompt changes to remind you that the system will let you do anything you want. Do you know what gets blown away by this command?

rm –rf /

If you just shuddered from the bad memories of that awful day, go ahead and use the root account. Once bitten, twice shy.

Use sudo. And don’t blow stuff up. 

About

Nick Hardiman builds and maintains the infrastructure required to run Internet services. Nick deals with the lower layers of the Internet - the machines, networks, operating systems, and applications. Nick's job stops there, and he hands over to the ...

10 comments
Nick Hardiman
Nick Hardiman

Some really good points here. Who would want to see a sudo config file more like Apache's 2,000 lines of examples and explanations? 

I don't know about any checksum feature. Sounds security-related, so is that to do with sudo, or with something like tripwire or debsums?

kevlar700
kevlar700

>> DT2

>> So, you're saing that one cant issue the following command if they're using sudo?

>> sudo rm -rf /

Not if you are using sudo properly.

 As you should be using it to allow only certain commands and arguments. Of course it is best to use it instead of root where required even if just for logging purposes.


If you want to edit files like /etc/fw you should add sudoedit /etc/fw which prevents the editor running other commands, something vi under su would not.

Also the article is a little wrong in that sudo has been heavily used for well over a decade and root still has to be permitted by the kernel (schg, chflags, RBAC).

 It is still quite funny to see how many even developers are totally ignorant of sudo's power and believe newer and far inferior technologies like polkit fill in the gaps.

You can easily have it allow you to update the system or install packages without a password perhaps as a dedicated user on a seperate console that automatically logs in.


You can have it allow a password to be required everytime or even a One time password for certain users commands or logins from the network or any combination.

A recently added feature is checking the checksum of a file before executing it.

It's a real shame distros don't ship sudoers files for useful packages and commands but turned off by default (the author not wanting generalised insecurities pushed on users) as it is far easier for users to get to grips with and control as well as being far more secure than polkit and so atleast users could reduce the generalised insecurities easily which they can't on a so called 'modern' linux desktop.

rick.jury
rick.jury

good article but when are you doing episode II 'how to configure up sudo on a box'. I'd like to read that too.

ps..

bad .   

haha I once typed this: rm -rf /* instead of this rm -rf ./* (thankfully not as root so I blew away only most of an apps file systems). it was a great test of the fault tolerant cluster for that app!

DT2
DT2

So, you're saing that one cant issue the following command if they're using sudo?

sudo rm -rf /

marcdw
marcdw

Regarding the sudo annoyance thing I now have oft-needed sudo commands aliased as I do forget to preface a command with sudo sometimes.

Even though I'm the only user on my machines I never "turn off" the password option. It's tempting but you never know...

henry
henry

Hey Nick

Loved that article

If you could do some more articles like this I could learn more of the basic stuff l need to know to move many of my client over to Linux. Lots of the contributors write very general articles and seem to avoid the real “nuts and bolts” of what works and what does not. Refreshing one this one Nick. Keep up the good work. Henry New Zealand

Nick Hardiman
Nick Hardiman

@marcdw sudo aliases - can you give me an example? "sct" as an alias for "sudo cat", maybe? 

Nick Hardiman
Nick Hardiman

@henry Thanks - I need the encouragement sometimes! What would you like to see next? What's the first nut or bolt that pops into your head?


marcdw
marcdw

@Nick Hardiman  

Yeah, like that. By default Arch Linux included some of those. "scat"="sudo cat", "update"="sudo pacman -Syu" (something like that). Plus others I needed for reboot, halt, etc. (for some reason "halt" was no longer powering off the machine so now "halt"="sudo /sbin/halt -p").