Sherry Moore schrieb: > It's unclear to me whether this case is for the new GDM and ConsoleKit, > or for what has already been put back. In any case, here's the whole > story. > > 1. Background: mechanisms to invoke regular (slow) reboot and fast reboot > > 1.1 One time > > 1.1.1 Rebooting with "-p" or "-f" option >
> 1.1.2 Adding transient property group > > The transient property group only exists for and affects > the next reboot. > > > 1.1.3 Using interface provided by libscf > > int scf_fastreboot_default_set_transient(boolean_t val); > > "reboot" and "init 6" after calling the above functions > will do fast reboot by default (if true) or not (if > false). > > Option 1.1.1 requires solaris.system.shutdown authorization, which > a ConsoleUser has; options 1.1.2 and 1.1.2 requires all Solaris > authorizations. > Do you mean 'all privileges'? As Darren mentioned there is an architecture problem here. Requiring more privilege to set a temporary override than to change a persistent default appears to be very wrong. For this case it is moot to discuss whether the problem is with SMF not allowing creation of these transient properties with 'only' a given authorization or with this choice of mechanism by the fast reboot project. But until this problem is fixed at the root, it seems better to add a workaround mechanism [*] to achieve the right behavior instead of specifying the wrong behavior. - J?rg [*] One way to do that is to add a privileged helper that checks for the solaris.system.shutdown authorization and then sets the transient override (probably using method 1.1.3). It might be simplest to make that helper setuid 0, because a mechanism that uses a "Shutdown User" profile to do this via pfexec is harder to remove, if the issue gets fixed on the fast reboot or SMF end. > There is no mechanism in the current SMF framework > to grant such service-based authorization. To add such support > requires additional framework in SMF, whose design is in progress, > but will not be available for the next OpenSolaris release. > There's actually no ETA for the framework at this point. >
