This probably belongs in a discussion off the case, but we can do
this for further conversation.
> >
> > 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.
>
> I am not sure what "they" you are talking about. GDM and ConsoleKit do
> use D-Bus for all IPC.
I'll admit I am not that knowlegable on D-Bus API's and
interactions, but there appears to be a deprecation of HAL in favor of
new things, including ConsoleKit. And somehow, it appears to not be
the hardware abstraction which is going away, but a specific set of
bits (or maybe some changing of the API's). Maybe what I need (and
possibly other reviewers) is some overall picture of how this will all
play in (Open)Solaris and how other services or applications might and
do interact. It will certainly help in the evolution of Power
Management usability.
Thanks!
---- Randy
>
> > > - 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)
>
> Although ConsoleKit does support some ability to shutdown and restart
> the system, there is no reason we need to make use of it if there are
> other, better interfaces available to use. Perhaps ConsoleKit isn't
> the best interface to use to manage shutdown and restart?
>
> In the ConsoleKit ARC case, it was never proposed that ConsoleKit should
> be the "one true" restart and shutdown mechanism on Solaris. Instead,
> the Desktop team just made a reasonable effort to make sure that if the
> ConsoleKit interfaces are called that it does something reasonable.
>
> That said, ConsoleKit is an option we can consider. If a project team
> at Sun wants to enhance ConsoleKit so that it does this job, there is
> no reason we can not do that. I just recommend that if we do this,
> we work with the upstream community to design a solution that is designed to
> work well across different platforms that ConsoleKit
> supports.
>
> However, if we decide that Solaris should not use ConsoleKit for
> shutdown and reboot, then it probably makes more sense to disable these
> ConsoleKit interfaces and make the GDM GUI instead use whatever
> interfaces make the most sense on Solaris. Note I am talking about
> the "Shutdown" and "Reboot" buttons that can appear on the GDM GUI if
> the "gdm" user has the solaris.system.shutdown authority, which is
> not the case on Solaris by default.
>
> > > 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?
>
> The D-Bus messages are directed to ConsoleKit, which takes care of
> shutting down or restarting the system.
>
> > 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.
>
> I agree that it would be best to manage this with one solution and
> set of interfaces. If we decide that ConsoleKit is not the best
> daemon to manage this, then it makes sense to disable this feature.
> That would simply be a matter of making the ConsoleKit scripts for
> reboot and shutdown no-ops, so that any requests are ignored.
>
> > > 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.
>
> This is not a limitation of D-Bus. You can use D-Bus to pass any
> information you like to any process, assuming that the interfaces are
> defined. We could enhance ConsoleKit's D-Bus interface to support
> passing in additional options if we want. Or we could use some other
> program to manage this, which could use D-Bus.
>
> > > 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.
>
> If we decide to solve this problem using an external module, such as
> ConsoleKit, then we should work with the upstream community in adding
> the needed features. If we use our own home-built solution, then that
> obviously requires less coordination and negotiation.
>
> Brian
>
