You can hardly mention the sudo command without recalling the hilarious XKCD strip about making sandwiches. It does seem like sudo is the magic power to make a Linux system do what you want. The only problem is that those superpowers are not something to be taken lightly.
sudo can handle that use case very easily.
Why?
As a simple example, suppose you like to shut your computer down at the end of the day. You run the shutdown command from the terminal but it doesn’t work because you aren’t root. You then have to do it again with sudo and if you haven’t logged in lately, provide your password. Ugh.
In my case, I got to thinking about this when I needed to manipulate the dbus service in a startup script. I wanted the script to manipulate just that service as a normal user and not prompt for a password, especially since some users don’t have sudo powers anyway. Either way, you would like a way to let normal users run very specific commands without additional permission.
A Simple But Bad Way
Your first thought might be to wrap the code in a shell script owned by root and set the suid bit so that when you execute it, the script elevates to having root access. That will work, but it seems like a potential security problem. After all, a script could do anything. Are you sure there is no way for a user to force it to do something else? Are you really sure?
Granted, you always have to think about this. If you, say, allowed someone to run emacs as root, that person could then open a shell and have full access to the system even if they didn’t otherwise have root access. That’s not good. But it is usually easier to reason about programs that have specific functions instead of a general-purpose shell script.
Configuration
That’s where sudo comes in. There’s really only one place to set up sudo, although most modern distributions have that one place read files from a second place that you can also use. The primary place is /etc/sudoers and, as you would guess, you need to be root to change that file. In fact, you shouldn’t open it with a regular editor at all. Use visudo which verifies you aren’t going to lock yourself out of root access by messing up this file. That would be very bad on systems where there is no way to log in directly as root.
When you use visudo, an editor launches. These days that’s often nano by default, although vi is the historic choice as you can see by the name. If you prefer something else, the tool will pick up your VISUAL or EDITOR environment variable. Well… sort of.
The authors of visudo and sudo were paranoid and rightfully so. There are options to remove all environment variables before running a command or to preserve just selected ones. So most of the time if you try to set one of these environment variables it is wiped out by sudo. To fix that, you’ll have to survive with whatever editor you get by default one time. You can preserve the environment variables and provide a list of accepted editors by putting this near the top of the file:
Defaults env_reset Defaults env_keep=VISUAL Defaults env_keep=EDITOR Defaults editor=/usr/bin/nano:/usr/bin/emacs:/usr/bin/vi
Keep in mind that your DISPLAY variable won’t go through either, so don’t expect a GUI editor to work without some further configuration changes.
If visudo doesn’t like your changes because of a syntax error it will ask you what to do. Press ? to see your options. You can tell it save anyway, but I don’t recommend that.
Now What?
There are many arcane syntax commands you can put in sudoers to get different effects. In this case, we want to run a command like shutdown or service without a password for a specific user. Say the user is jolly_wrencher:
jolly_wrencher ALL= NOPASSWD: /usr/sbin/shutdown
This tells sudo that the user on all machines can run the command with no password. If the command takes parameters, the user is free to supply them. However, you can also provide parameters that must match or use a quoted space to imply no arguments allowed.
In the case of something that is disallowed, sudo may still let you run the command if you provide the password and you were otherwise allowed to run it. Otherwise, no dice.
For example, with the dbus example, I used two lines:
jolly_wrencher ALL= NOPASSWD: /usr/sbin/service dbus status jolly_wrencher ALL= NOPASSWD: /usr/sbin/service dbus --full-restart
Easier Maintenance
Many distributions will now have a final line in the sudoers file that looks like this:
#includedir /etc/sudoers.d
This will scan the directory named for files (unless they have ~ or . characters in the name) and process them, too. So in my case, I have the two lines about dbus in a file /etc/sudoers.d/dbus-service. You still should use visudo to edit. In recent versions, you just pass the name of the file you want to edit. Old versions needed a -f option. After editing, the system checks the entire sudoers file for errors, so it is safer than editing the files directly.
There’s quite a bit more you can do with sudoand sudoers. However, you should resist the urge to do too much. It is easy to make assumptions about security that get you in trouble. However, there are always cases where you need this kind of power and, as usual, Linux doesn’t disappoint.
As a ‘single user’ home system, I don’t find much, if any, use for sudo. It seems much easier for me to just ‘su -‘ and do the work I need and then exit back to user space when done. I don’t mind entering the ‘root’ password as that is part of Linux security. No big deal to me.
Thanks for the good read though.
I don’t like doing this because it’s too easy to type something bad at a root prompt. As a software developer and sys admin I am constantly deleting and moving stuff around, typing the wrong thing in the wrong place can be a disaster. Whenever I type sudo I remember the Spiderman lecture and I take extra care. Also with sudo all your commands are going into one command history so it’s easier to remember what you typed.
I’ve never had a problem with that as a software developer (since 1982) and as sys admin as well. But then I’ve always been comfortable with a command prompt ever since CPM/86 and DOS. That isn’t many commands that you can really make a mess of your system with anyway. Most times when I am ‘root’ I am doing things like modifying/creating settings files (nfs, samba, wifi, fstab, etc… ) with nano or vi, mounting file systems, apt commands, things like that. Very rare that I use the ‘rm’ command recursively for example while root that could destroy one’s system. I just have ‘never’ found working from the command-line as ‘dangerous’ as it is portrayed — as root or user. But that is just me.
I’ve never erased all. But I remember with annoyance erasing a file of email. I was just careless but it had nothing to do with root.
We do need to be careful, a slip can be fatal. Being root just magnifies the damage. But there’s nothing on my system that can’t be reinstalled, while my home directory is what matters.
Me neither. This sudo dogma seems bizarre. The one time I remember doing something catastrophic with root a long time ago was a `rm -rf $variable/` on a remote system where `$variable` wasn’t defined on the other end.
Sure, don’t run your browser as root because it’s complex enough to be untrustable, but I have no qualms about ssh’ing somewhere as root or leaving a root terminal open (as long as I lock the desktop when I get up of course).
Though I’ve just remembered that I have `HISTCONTROL=ignoreboth`, so any dangerous commands get preceded by a space so they don’t get saved in the history (Ctrl+R, Enter has bitten me), so maybe the act of beginning a command with the space puts me in “careful” mode.
I am a bit more conservative here. I am only in a root session as long as I have to be. For example when I decide it is time to backup my /home folder. I jump in as root and run my backup script to rsync all users and data stored in /home to the home server. When done, I immediately logout. I think that is good practice to stay out of root as long as root access isn’t needed. That’s my opinion — at work, or home.
As for ssh. I always login as myself and once on the machine, then login as root using ‘su -‘ if needed. Don’t know if that is more secure or not, but that’s been my practice.
@X: 👍
setting up a git project for etc on another local box has saved me more than once, and I follow the same guideline as you unless I am going through some massive multi-step thing that usually only occurs when the instance is being set up and not in use yet.
One problem is security issues are presented either as an old Un*x multiuser issue, or lowest-common-denominator Linux users needing protection from making disastrous changes (which sudo only prevents so much, Anyways) For a while I experimented with Canadian Shark linux, simply because the default user was admin, I had minimal need for internet, I just wanted to experiment with different distros. Kali used to do this too, which made some sense because so much of penetration testing is about getting root, of course a seasoned pen tester is going to want root on their own machine at all times. But they had decided to be the #1 compsec for training and certification (much like Red Hat embraced linux certification, and had wanna-bes and linux newbies and even offer Windows Linux Subsystem Kali, so I think user security risks were too much (I assume. Obviously I have multiple issues with Kali, I don’t follow them too closely) on the other extreme, trying to do anything under Ubuntu is extra onerous. My point is that it’s easy to get alienated from the discussion, when you have some competence on a single-user system. I think those of us who aren’t newbie admins or using a multi-user system should feel more invested in the issue, and the linux community isn’t asking our opinion!
Here’s a use for sudo: “sudo su -“. That way, you can still “become” root, but your system doesn’t have a root password and you can’t login as root.
+1 and of course have the good ol ‘# ‘ root prompt to remind you that shell is ‘live’
On my Debian boxen I too simply ssh in as my user level and then “su -” to root.
On my RaspPis I ssh in and use sudo as that’s how raspian is set up, works just fine of course.
On my Mac I use sudo as well..
As above I also exit root shells promptly after use. Other than sudo ones as they time out :-)
Can’t have a linux article without a HILARIOUS xkcd comic! Here’s my favourite https://xkcd.com/1756/
Missed mentioning that you can use ‘sudo -l’ to see a list of commands you’re allowed to run
It could be worth mentioning that delegating privileged access to commands should only be done after
I’m pretty sure the suid bit is ignore for shell scripts. Someone correct me if I’m wrong.
It isn’t quite that simple: https://www.in-ulm.de/~mascheck/various/shebang/#setuid
It’s actually a quoted empty string, not a quoted space, that will imply that the command is not allowed to be run with any arguments.
Sudo doesn’t actually provide security on most desktops. If you get my home folder, you get all my passwords, financial info, basically everything.
If you get root, you get that plus maybe it’s a bit easier to hide what you’re doing.
But it is useful as an extra hoop to jump through, since Linux commands are horrible about asking confirmation(I really don’t think anything can be a good programming language and good interactive shell at the same time)
You’re assuming that the alternative to being root is being you, a fairly privileged user, rather than being perhaps www-data or similar.
Also, you should be able to rm your home dir at any time knowing it’s safely backed up. Root can destroy your backups.
“Make me a sandwich.”, “What, make it yourself.”, “Sudo make me a sandwich.”, “F*ck you, I use Windows!”
“There are options to remove all environment variables before running a command or to preserve just selected ones. So most of the time if you try to set one of these environment variables it is wiped out by sudo. **To fix that, you’ll have to survive with whatever editor you get by default one time.**”
Actually you can change the EDITOR variable on the command line when invoking visudo for the first time to override the default system editor. For example, to use nano do this:
EDITOR=nano visudo
…and visudo will open the sudoers file in nano instead of vim/emacs/pico/micro or whichever editor the distro maintainer prefers, while preserving its safety protocols.
That’s assuming — I think — that the environment hasn’t been wiped out. visudo runs at elevation, so if you clobber the environment, EDITOR goes with it. Now, if you don’t do that or if you deliberately pass EDITOR, yes. But in many cases you will have to accept the default until you can edit the sudoers options.
What happens if you enter sudo sudo?
Thanks to Hackaday, sudo creator speaks:
* Interview: Inventing The Unix “sudo” Command, May 28, 2014 by Aleksandar Bradic
https://hackaday.com/2014/05/28/interview-inventing-the-unix-sudo-command
* Inventing the Unix “sudo” command – Interview with Bob Coggeshall [08:02]
https://www.youtube.com/watch?v=LaAwl3HN5ds
Oh gee, I’ve gotten old.