On Mon, Mar 23, 2015 at 5:46 AM, Peter Humphrey <pe...@prh.myzen.co.uk> wrote: > > The remaining question is: why is the user not allowed to halt it? >
Keep in mind there are many ways that a unix-like OS can be used. It could be running on a laptop, or it could be running on a multi-user system where 50 people are logged in at any given time. In the former case you want a desktop-like experience where the user can just hit the shutdown button, and in the latter case you don't want users powering off the server which might be 4 states away. The old solution to this was just having the system owner run sudo poweroff. Then desktop environments came up with a way to allow a logged in user to send a command back to the display manager (which runs as root) to tell it to shut down the system, and made whether that is allowed configurable. The most recent evolution of this is consolekit/logind, which distinguishes users logged in at the system console from those logged in remotely and grants the authority to shutdown the system if you're local. This approach also does things like assign permissions to audio devices as well, so that only the person sitting at the console can spy on the console using the microphone and you don't need to control this manually using an audio group. The other trend is for unprivileged processes access privileged functions via dbus, controlled by polkit. This allows granular control over what users/groups/etc can run what functions, potentially based on whether they're at a local console or not. You can even control that particular functions require a root password or for the user to re-enter their password. This puts all the policy rules in /etc and reduces the amount of per-application configuration. It is a bit like sudoers, but with more fine-grained control and without getting into hard-coding command lines (which can be a bit clumsy). The traditional downside to this approach has been the need to run dbus, but this is moving into the kernel and the intent is to encourage processes to utilize it as the main IPC mechanism. The end goal is to try to get reasonable default behavior without requiring either desktop or server administrators to have to do much, or to have to designate a distro as being primarily desktop vs server in nature. On a server nobody is logged in via the console, so you get restricted privileges by default. On a desktop the main user is logged in via the console and can use their webcam+mic, but others who might be allowed to login cannot remotely connect over the network and spy on the same. However, all of this is configurable - you can stick rules in /etc which change these behaviors. -- Rich
