15.7 Restricting sudo to Specific Commands

Right, so you’ve decided you don’t want to hand over the keys to the entire kingdom. Smart. Giving a user full, unfettered sudo access is like giving them a bazooka to open a walnut: effective, but the cleanup is going to be spectacular. The real power of sudo isn’t in giving someone all of root’s power; it’s in the surgical precision of delegating only the commands they absolutely need to do their job. Nothing more.

15.6 sudo Logging: /var/log/auth.log and journald

Right, so you’ve configured sudo to let your users do powerful things without handing out the actual root password. Smart move. But power without accountability is how you get a server that suddenly decides to host a crypto-mining operation for the “Minecraft Fan Club.” The entire point of sudo is delegated privilege, and the entire point of delegated privilege is knowing who did what and when. That’s where logging comes in, and it’s non-negotiable.

15.5 NOPASSWD: When and How to Use It Safely

Alright, let’s talk about the NOPASSWD tag. This is the sudo equivalent of handing your friend your credit card and saying, “Just get the groceries, don’t buy a jet ski.” It’s incredibly powerful and, if used carelessly, a fantastic way to create a gaping security hole. But sometimes, for automation and specific service accounts, entering a password is either impossible or a massive pain. That’s where NOPASSWD comes in. The rule is simple: when a user runs a command tagged with NOPASSWD in the sudoers file, sudo will not ask for their password. It just executes the command with elevated privileges. The syntax in /etc/sudoers is the same as a normal rule, you just slap NOPASSWD: in front of the command list.

15.4 sudo -i vs sudo su: Differences in Environment

Right, so you’ve decided to elevate your privileges. Good for you. You’ve probably typed sudo a thousand times, but when you need a full, interactive root shell, the two incantations you’ll see most often are sudo -i and sudo su -. They look like they do the same thing, and in a lot of cases, the end result seems identical. But the devil, and a whole lot of security and environment nuance, is in the details. Let’s crack this nut open.

15.3 visudo: The Only Safe Way to Edit sudoers

Right, let’s talk about visudo. This is one of those rare, non-negotiable best practices in system administration. You could just open /etc/sudoers in vim, nano, or even (shudder) notepad.exe if you’re feeling particularly self-destructive. But you absolutely should not. Here’s why. The sudoers file is the single point of truth for who gets to do what with sudo. If you introduce a syntax error into this file—a missing comma, a stray quote, a typo in a hostname—you can completely lock yourself and every other admin out of root access. The system will refuse to run sudo at all until the error is fixed. And how do you fix it? Without sudo, you can’t edit the file you just broke. You’d have to reboot into single-user mode or use a live CD. It’s a spectacularly annoying and entirely preventable self-own.

15.2 The sudoers File: Location, Format, and Rules

Alright, let’s get our hands dirty with the sudoers file. This is the absolute nerve center of sudo, the sacred text that dictates who gets to do what. It’s a single file, /etc/sudoers, that holds all the power, and for that reason, you should treat it with the respect of a live explosive. One misplaced character and you could lock yourself out of your own system or, worse, create a gaping security hole. We never, ever edit this file directly with a regular text editor. We use visudo. This isn’t a suggestion; it’s the law. visudo locks the file to prevent simultaneous edits and, most importantly, it performs a syntax check on the file before saving it. If you mess up, it will politely (or not so politely) stop you from saving a broken configuration, saving you from a world of pain. Trust me, you want this safety net.

15.1 What sudo Does: Running Commands as Another User

Right, let’s talk about sudo. It’s not just a magic prefix that makes things work; it’s the Swiss Army knife of privilege delegation. You use it when you need to run a command as another user, most commonly the all-powerful root user, without having to log out and log back in as them. It’s the difference between handing someone the keys to the server room and just letting them flip a specific light switch. The former is su (which we’ll get to), the latter is sudo, and it’s infinitely more secure and auditable.

— joke —

...