4 ms·

I recommend not using root privileges unnecessarily. `systemctl status` and most other querying commands don't need root, while the dangerous things like `syste

I recommend not using root privileges unnecessarily. `systemctl status` and most other querying commands don't need root, while the dangerous things like `systemctl exit` do.

usr1106 5y ago
Sure, but some systems do poweroff without being root. Has happened to me, don't remember the details. Maybe a polkit thing because users are supposed to shut down their own laptop?
- CraigJPerry 5y ago
  Yeah true, if the user is logged on via a physical tty or local X session (i.e. the policykit subject.local attribute == true) then in some distros they will get permission to shutdown or reboot. They won’t have the permission if connected remotely though.
TimWolla 5y ago
I can't say what they had in mind when typing `systemctl`. Even they couldn't. Because of the delay in the shutdown to cleanly stop the services, they had already forgotten that they just exited a SSH session and thus the connection between the machine being dead and typing `exit` was not obvious. Maybe it was `systemctl status`. Maybe it was intended to be a `reload` (which would require elevated privileges).
- AceJohnny2 5y ago
  GP's point was more that you shouldn't be able to casually do "systemctl exit" in a standard shell session. All privileged operations should require a sudo. One might be tempted to just do a full "sudo shell" to perform all systemctl operations, but GP's point is that many of the "observation" actions don't require sudo in the first place! In the end, the user being able to accidentally run "systemctl exit" may be indicative of a policy issue (ie don't allow root logins).
  - Rapzid 5y ago
    But may not be. Maybe the policy is fine and changing it based on one machine shutdown is not worth the costs.
  - iso1631 5y ago
    All sudo actions on my machines are logged to a remote syslog server (and locally to /var/log/auth.log, which is rotated, compressed, and kept far longer than other logs). That certainly used to be standard. You can't log on as root, you have to log on as your own user and elevate to root (even if that's all you do with sudo), so there's a trail there. This article suggests there are ways for programs to issue unaudited commands with elevated privileges to systemd. "Systemd has a D-Bus interface that people can use, there's hardware events that may trigger a reboot, there are various programs that may decide to ask systemd to reboot the system, and under some circumstances systemd itself can decide that a particular, harmless looking process failure or 'systemctl' transaction actually will trigger a reboot through some weird chain of dependencies and systemd unit settings" Complaining about systemd is as old as systemd, and borders on a religious war, a proxy towards "modern linux" and "old school unix" methods.

I recommend not using root privileges unnecessarily. `systemctl status` and most other querying commands don't need root, while the dangerous things like `systemctl exit` do.

usr1106 5y ago

Sure, but some systems do poweroff without being root. Has happened to me, don't remember the details. Maybe a polkit thing because users are supposed to shut down their own laptop?

CraigJPerry 5y ago
Yeah true, if the user is logged on via a physical tty or local X session (i.e. the policykit subject.local attribute == true) then in some distros they will get permission to shutdown or reboot. They won’t have the permission if connected remotely though.

TimWolla 5y ago

I can't say what they had in mind when typing `systemctl`. Even they couldn't. Because of the delay in the shutdown to cleanly stop the services, they had already forgotten that they just exited a SSH session and thus the connection between the machine being dead and typing `exit` was not obvious. Maybe it was `systemctl status`. Maybe it was intended to be a `reload` (which would require elevated privileges).

AceJohnny2 5y ago
GP's point was more that you shouldn't be able to casually do "systemctl exit" in a standard shell session. All privileged operations should require a sudo. One might be tempted to just do a full "sudo shell" to perform all systemctl operations, but GP's point is that many of the "observation" actions don't require sudo in the first place! In the end, the user being able to accidentally run "systemctl exit" may be indicative of a policy issue (ie don't allow root logins).
- Rapzid 5y ago
  But may not be. Maybe the policy is fine and changing it based on one machine shutdown is not worth the costs.
- iso1631 5y ago
  All sudo actions on my machines are logged to a remote syslog server (and locally to /var/log/auth.log, which is rotated, compressed, and kept far longer than other logs). That certainly used to be standard. You can't log on as root, you have to log on as your own user and elevate to root (even if that's all you do with sudo), so there's a trail there. This article suggests there are ways for programs to issue unaudited commands with elevated privileges to systemd. "Systemd has a D-Bus interface that people can use, there's hardware events that may trigger a reboot, there are various programs that may decide to ask systemd to reboot the system, and under some circumstances systemd itself can decide that a particular, harmless looking process failure or 'systemctl' transaction actually will trigger a reboot through some weird chain of dependencies and systemd unit settings" Complaining about systemd is as old as systemd, and borders on a religious war, a proxy towards "modern linux" and "old school unix" methods.