ConsoleKit shutdown service, a different viewpoint
William Jon McCann
mccann at jhu.edu
Fri Feb 1 08:05:02 PST 2008
On Feb 1, 2008 8:05 AM, Rob Taylor <rob.taylor at codethink.co.uk> wrote:
> I have a slightly different viewpoint on why it might not be a good idea
> to have a shutdown service in ConsoleKit: what if you want more input to
> the shutdown decision than just what consoles are currently active?
PolicyKit handles the policy decision. So, the decision can be based
on whatever information is available to it. Which is theoretically
> A good usecase to consider here is if an administrator is installing
> packages or doing a distribution upgrade - how would this get fed into
> the decision?
One idea of how this could work now is that ConsoleKit could reject
the initial request and return an error to the caller saying that a
higher privilege is required, say (hypothetically):
org.freedesktop.consolekit.system.restart-system-busy (or something)
Which would require auth_admin.
> Can you have policy so a user with sufficient privileges can shut down a
> box though another user's logged in?
> Can you have response to a shutdown request - we have an example usecase
> on the OHM wiki  where one console user has left a large download
> going - could a user requesting a shutdown get informed of the situation?
That is certainly something we should consider.
> Another example is an edge case of a simultaneous shut-down and suspend
> to disk, one should always take precedence, but if a suspend is in
> progress, the shutdown should probably not happen.
Sure. Well, having these functions come from a single source is one
way to handle this. Then the operation should probably just be
synchronous or refuse to service new requests. Historically we've had
so many different places that provide this functionality that this
kind of cooperation was difficult. And perhaps looking forward we'll
need more cooperation with the init system.
More information about the hal