Re: [gentoo-user] How to poweroff the system from user?

[Rich Freeman]

On Mon, Mar 23, 2015 at 5:46 AM, Peter Humphrey <peter@××××××××××××.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