FWIW, I have several issues here. To start (and it isn't directed
to the submitters, but to the imported API's) it limits the possible
selections: especially stop() and restart(), as if there are no other
options (at least one that I know of). It also adds yet another
service responsible for doing system-wide control (again,
stop()/restart() - and intends to do it with a shell script).
On Wed, 26 Aug 2009, Brian Cameron wrote:
>
> Jedy/Sherry:
>
> > Sherry gave us the whole story. The logic you mentioned will be
> > implemented in ConsoleKit which will be integrated after b128. So
> > currently, we have 2 options. The first one is to wait ConsoleKit's
> > integration. The second one is to integrate the current fast reboot
> > support of GNOME restart dialog at b124 and then update it after
> > ConsoleKit's integration after b128.
>
> Note that ConsoleKit currently does not support the ability to respond
> to different types of reboot options. So, I assume part of the plan to
> use ConsoleKit in the future is to enhance it so it can support doing
> this.
IMHO, it is sufficient for the restart dialog to only have
'Restart", as other choices are effectively TMI. The majority of
users will gladly take the default policy as to what restart() means
(fast, through BIOS, whatever). Users that have a clue as to the
difference between 'reboot -f' and 'reboot -p' will be happy to do
that on a CLI. And as long as there is a decent API to select what
the default reboot properties should be, I don't really see that the
added complexity is worth it.
>
> > > 2. Options for GDM
> > >
> > > 2.1 With unmodified HAL
> > >
> > > Currently GDM uses the interfaces provided by HAL. hald runs
> > > as a privileged process and checks for required
> > > authorizations. If the caller has sufficient authorization to,
> > > say reboot, it will invoke hal-system-power-reboot-sunos.sh.
>
> GDM and ConsoleKit do not use HAL at all today. GDM/ConsoleKit support
> shutdown/reboot as follows today:
This gets to my original issue: there is no common methodology for
handling system services. They should be using D-Bus (or something
like D-Bus), and let the backend services be whatever.
>
> - The new GDM rewrite has a login GUI which checks the
> solaris.system.shutdown RBAC key directly. If the "gdm" user has
> this authorization, then GDM will present the "Shutdown" and "Reboot"
> buttons in the dialog. If they are pressed, a message is passed to
> ConsoleKit via D-Bus.
>
> - ConsoleKit checks to see if the user who passed the D-Bus message has
> the solaris.system.shutdown RBAC key defined. If so, it will call a
> script. One script for shutdown and another script for reboot.
> The shutdown script calls "/sbin/init 5" and the reboot script calls
> "/sbin/init 6".
(Not sure I like this at all)
>
> Note that any user can call ConsoleKit with a message to request
> shutdown or reboot. If it was passed in from the GDM GUI by clicking
> on the associated button, then the user would be the "gdm" user. But
> ConsoleKit will only call the shutdown/reboot script if the calling
> user has the solaris.system.shutdown authority.
>
> In GDM 2.20 and earlier (currently used in Nevada and OpenSolaris), it
> works much the same, with the following differences:
>
> - ConsoleKit is not used at all, GDM does all the work.
> - The shutdown/reboot commands are defined to be "/sbin/init 5" and
> "/sbin/init 6" in the GDM configuration.
> - The new GDM uses D-Bus messages for IPC while the old GDM uses a
> private socket which can be accessed directly or via the
> gdmflexiserver program. See "man gdmflexiserver" to see the
> commands used to trigger reboot or shutdown.
Are these D-Bus messages directed towards the ConsoleKit daemon, to
hald, or something that happens to be listening?
As I understand the description, the ConsoleKit daemon is waiting
for D-Bus messages and will respond to a 'restart' request. What if
hald also responds? init(1m) does audit, but will we get the desired
information (this is what I seem to be wrestling with suspend right
now)? I would much rather see a single service (possibly a merge of
ConsoleKit, HAL, and powerd) that will (among other things) respond to
D-Bus requests, audit the actual requesting user/application, and
perform the proper action, hopefully based on some larger policy that
might determine that ConsoleKit Manager sessions are not allowed to
stop/restart the system.
>
> As I say above, ConsoleKit calls a script to reboot or shutdown, so it
> would be easier to integrate a solution that invokes shutdown/reboot
> via this script.
>
> The main problem with GDM and ConsoleKit is that ConsoleKit only
> provides a single D-Bus interface for "reboot" and does not currently
> provide any way to pass in any options regarding what kind of reboot
> is requested.
Again, I don't believe this is bad. For the vast majority of users,
the default action is plenty sufficient. For the others, they know
how to use the alternate methods or to change the default.
>
> I am sure the existing D-Bus messages could be augmented to allow more
> flexibility in specifying how the system should reboot. Likewise, the
> GDM login GUI could be augmented to allow users to specify what kind of
> reboot they want to do if the "gdm" user has the
> solaris.system.shutdown key defined.
Here, I believe that D-Bus needs some extension to support a larger
variety of controls, including platform-private controls. But
certainly it is beyond this case.
>
> That said, we should probably code this in a general way so that we
> can get the code upstream. We probably do not want to code a solution
> that works specific to how reboot works on Solaris. Instead, we should
> probably augment ConsoleKit so that reboot can be easily enhanced to
> support different kinds of reboot operations on any distribution.
> Otherwise, we will not be able to get this sort of change upstream, and
> be stuck maintaining a Solaris-specific patch ourselves. Maintaining
> our own patch would not be the end of the world, but it is obviously
> easier to maintain the code if we can get our changes upstream.
>
> So, to design this properly, there probably should be some discussion
> about it first on the public ConsoleKit mailing list. That way we can
> make sure that any design considerations from other distributions are
> taken into account as well.
>
> ConsoleKit at lists.freedesktop.org
>
> In other words, I did not have any serious problems with your proposal.
> More of a concern that we are trying to design new ConsoleKit features
> without including the upstream community in the design process.
>
A place where I do agree, we should be working with the upstream
community to provide these controls.
On the other hand, I don't have voting rights here, just comment
rights (which I did choose to exercise).
Cheers!
---- Randy
