[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] battery-module: run an command on alarm



On Thu, 22 Jun 2006 08:57:21 +0200 Stephan Wezel <s.wezel@arcor.de> babbled:

> Am Thu, 22 Jun 2006 08:11:54 +0900
> schrieb Carsten Haitzler (The Rasterman) <raster@rasterman.com>:
> 
> > On Wed, 21 Jun 2006 23:00:30 +0200 Stephan Wezel <s.wezel@arcor.de>
> > babbled:
> > 
> > > Hi,
> > > i have written a patch with which the battery-module can run an
> > > command on alarm.
> > > E.g when the battery drops under 10 min remaining time then you
> > > can initiate the shutdown of the system.
> > > 
> > > the command is currently executet via the system-fn call. If it is
> > > there a better methode to do it then let me know it.
> > > 
> > > Regards
> > > 
> > > Stephan Wezel
> > 
> > i actually didn't want to do this. running a command is powerful- but
> > not very user friendly. the fact is that this feature appeared for a
> > reason - to shut down, suspend or such given a condition. being able
> > to shut down, suspend etc. from e directly is already a desired thing
> > - but this requires punching holes into root access, and i haven't
> > done that yet. but the proper solution (imho) is to do this (provide
> > e calls in e itself to exit e, restart e, logout, shutdown, reboot,
> > suspend, hibernate etc.) then provide a simple config dialog of "at
> > X% battery do: nothing, warning dialog, shutdown, suspend, ... etc.".
> > as a user should not have to know some obscure incantation to have
> > something like this work. it should be a simple choice. then e will
> > take care of doing that specific action. (as doing it your way a user
> > needs to figure out how to give themselevs root access - sudoers, or
> > whatever) and do it in a non-interactive way for these specific
> > commands, then actually know these commands etc. i'd rather push that
> > off int an abstracted api and a system config that defines what these
> > special suid root helper commands do (the system, admin or
> > distribution would define it in a system config or at compile time so
> > it works with the way their system works - this is specially needed
> > for suspend and hibernate at the moment as there are many different
> > ways to do that currently unlike shutdown and reboot which are
> > standard)
> yeah you are right in this case to simplify the choice for the user.
> And to gain security so that the user can only do things with
> root-rights, for these he has the rights to do it.
> I have done this in similar way as gkrellm it does.
> I would say everyone who knows how to get root access only(e.g. via
> sudo) for the needed command can use this patch :)
> 
> Now is the question how would looks like the helper to to the e.g.
> shutdown, reboot, suspend, hibernate:
> 
> 1. They could be standalone helper-programs which gets called from e.
> 2. Or they could be modules.

actually they HAVE to be helper-programs. modules are loadable .so's - and thus
run within the wm as the user of the wm - they have no privileges. cpufreq has
such a helper utility as part of being a module. if e does this it needs to
compile its own helper utils. the api would need to be a core part of e - like
e_syscontrol for example:

typedef enum _E_Syscontrol_Action
{
  E_SYSCONTROL_ACTION_RESTART,
  E_SYSCONTROL_ACTION_EXIT,
  E_SYSCONTROL_ACTION_LOGOUT,
  E_SYSCONTROL_ACTION_SHUTDOWN,
  E_SYSCONTROL_ACTION_REBOOT,
  E_SYSCONTROL_ACTION_SUSPEND,
  E_SYSCONTROL_ACTION_HIBERNATE
} E_Syscontrol_Action;

int e_syscontrol_do(E_Syscontrol_Action action);
int e_syscontrol_can_do(E_Syscontrol_Action action);

and as a core part of e these can be called by any part of e or modules. the
api calls here would take care of checking if the suid-root util exists and it
has the suid bit set and is owned by root, and if so - tell you that you can do
that action (return 1 from can_do()). the util is only needed for the last 4
actions. the first 3 i put in for completeness (the first 2 will replace the
existing restart and exit code) and adding a logout (that would possibly do
things like shut down all apps and wait for them to go away or a timeout to
expire before an exit. shutdown and reboot would do the same internally).

> The module-way has the capabilities that we can define a API which
> doesn't need a call of an external programm to run the helper.
> 
> A API could be look like this:
> 
> hasRights() 	// ro check if the user has the rights to do the command 
> doShutdown()	// to initiate the shutdown
> doReboot()	// reboot the machine
> etc.
> 
> the hasRights could either have an parameter for the command to check
> or we have for each command a seperate hasRights<command>-function
> 
> > 
> > > -- 
> > > Ein Ring, sie zu knechten, sie alle zu finden,
> > > Ins Dunkel zu treiben und ewig zu binden
> > > Im Lande Mordor, wo die Schatten drohn.
> > 
> > 
> 
> 
> -- 
> Ein Ring, sie zu knechten, sie alle zu finden,
> Ins Dunkel zu treiben und ewig zu binden
> Im Lande Mordor, wo die Schatten drohn.
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)