Avoiding Sudo Abuse

Sudo is just so easy. Put it in front of any command and magically you don't have to worry about permissions.

But it can get you into bad habits, thinking root permissions aren't a big deal, using them when you don't really need them.

Unfortunately, most distros' default setups encourage this sort of thinking for command-line users: they set things up so that you can't run important basic user functions without being root. Often you can't even read your own system logs except as root.

This made some sense in the days of multi-user systems, but it makes no sense for a single-user desktop or laptop. So here are a few ways to configure your system so you don't need sudo quite as often.

Suspend, Poweroff, Reboot

I had been using sudo poweroff, sudo reboot and sudo pm-suspend --auto-quirks. But on a systemd-enabled distro (which is most distros, unless you're bending over backwards to avoid systemd), you can add yourself to the power group and then you can use systemctl to power off, reboot or suspend.

Oh, wait: Debian doesn't have a power group. So you have to add one. Edit (as root, natch) /etc/group, and add a line like this:

power:x:130:youruser

After logging out and back in to reset your groups, you may be able to shut down with systemctl poweroff, suspend with systemctl suspend, and reboot with systemctl reboot.

I wonder if it's possible to make systemctl work with groups that already exist on Debian, like adm. But like so many systemd functions, I can't find any documentation whatsoever on this "power group" business. Is the name "power" hardwired into systemctl? Or what?

... except on a lot of machines that doesn't work.

These systemctl commands don't work on all systems. Randomly, it may or may not work, depending on what polkit decides it wants to let you do.

==== AUTHENTICATING FOR org.freedesktop.login1.set-wall-message ===
Authentication is required to set a wall message
Authenticating as: root
Password:

Failed to suspend system via logind: Access denied
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to start 'suspend.target'.
Authenticating as: root
Password:

I haven't found a way around this. These org.freedesktop strings don't correspond to anything in any of the /usr/share/polkit-1/actions/ files, and nobody seems to have a clue how polkit works, to the extent of being able to debug why it's granting or failing to grant permission for any given action.

Setting <allow_active>yes</allow_active> on the various suspend targets inside those files doesn't help. For instance, there are some elaborate suggested solutions for Ubuntu's polkit in How can I make shutdown not require admin password? but none of them worked for me on Raspbian or plain Debian.

A lot of these rules depend on whether your "session is active". Nobody explains what that means, but you can check it like this:

$ loginctl show-session $XDG_SESSION_ID --property=Active
Active=yes

Alas, that doesn't actually make polkit rules like <allow_active>yes</allow_active> actually work, and I haven't found any way to get polkit to report why it's blocking something or prompting for a password.

If you edit /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy, look for and change the allow_active rule to yes, you can get past the password prompt and hit another error:

$ systemctl suspend                                                 ~
Failed to suspend system via logind: Access denied
Failed to start suspend.target: Unit suspend.target is masked.

I give up: I've gone back to using sudo poweroff and sudo reboot on Raspbian.

WPA Supplicant

I used to use a complicated hash of commands like ip and ifup to configure my network, via a Python script I wrote called netscheme. But none of those commands are documented at all, they change frequently, and I got tired of maintaining it. Lately I've instead been using wpa_cli via a much simpler Python script I wrote called wpnet.py.

And yes, it abused sudo heavily. But it turns out that if you add

ctrl_interface_group=adm

You'll probably want to make it possible to read the wpa_supplicant.conf file as well:

sudo chmod 755 /etc/wpa_supplicant/

... but you can't do everything with wpa_cli

It's nice that you can run wpa_cli without sudo, but it can't actually do anything until wpa_supplicant is already running as root, so that needs sudo unless you want it running all the time whether or not you have a network.

The Arch wiki: Polkit has a nice example that's supposed to allow non-root users to start wpa_supplicant, but alas, it doesn't work on Debian (I wonder if it works on Arch either).

The same is true of DHCP. Both dhclient and dhcpcd will only work if run as root. Raspbian, which uses wpa_supplicant for all its networking, solves the DHCP problem by running both wpa_supplicant and dhcpcd all the time, just in case a network should appear.

Apache logs

How silly: apache web server logs aren't readable by default. You can change that in /etc/logrotate.d/apache2: Change the create line to something like

create 640 root adm

Presumably a similar approach works for most logs controlled by logrotate.

dmesg

Even sillier, a few years ago someone got the bright idea that users shouldn't be able to read dmesg output. You can fix that by adding

kernel.dmesg_restrict=0

More?

This list is very incomplete: it's just what I thought of off the top of my head one afternoon. Suggestions for things to add? Let me know.