Re: alarm?

On Thu, 12 Sep 2002 14:34:28 -0400
Jay Sekora <js_at_aq.org> wrote:
> [Disclaimer - I haven't actually done any work on GPE apps. But I'm
> hoping that an alarm mechanism would be flexible enough that non-GPE
> apps, or little one-off scripts, could use it as well without too
> much trouble. Incidentally, anybody know how OPIE/QPE handle this?
> Or are they single-user?]

This is really important, you are absolutely right!
So we need an additional commandline frontend to the rtcd...

> Hi. Seems to me that a good approach would be to allow apps to
> register alarms in the form of "when this alarm kicks off, run this
> command line as this user". The assumption would be that the command
> line would usually be something like
> /usr/bin/notify-my-own-weird-app-of-an-alarm 31FCE429
>
> where that is a little stub that either finds a running instance
> of /usr/bin/my-own-weird-app and signals it (via TCP/IP, X display
> properties, signals, or whatever) to display the alarm with ID
> "31FCE429", but it could also be something like
> /usr/bin/madplay /usr/local/mp3/wakey-wakey.mp3
> or
> /usr/bin/gpe-message "Time to take your meds"
>
> That would let individual apps that wanted to handle alarms do so
> in as simple or as complex a fashion as they chose.

Good point!
That would also solve an issue Joseph asked me about, i.e. to use the
alarm notificator from gpe-alarm for calendar alarms. You could then
simply call gpe-alarm as alarm handler for gpe-calendar! That's cool!

> That leaves the issue of what happens when the user isn't logged in.
> I wouldn't want to miss my plane because I happened to be demoing
> my ipaq as a different user when the alarm was supposed to have gone
> off. One approach would be to arrange for all past-due alarms to
> trigger when the person next logs in. Another is to have a textual
> description of the alarm and an app that can run as root to pop up
> a notification window, to at least let the person looking at the ipaq
> know that an alarm was supposed to have triggered. I think either
> behaviour should be configurable, because whether you want one, the
> other, both, or neither depends on how you generally use your ipaq
> (and whether you share it). But anyway, I think that an app that
> registers an alarm (commandline) should be required to also register
> a textual description of the alarm that could be used in some sort
> of "default" action if the command line can't be run. (That could
> also be useful in a GUI letting you cancel or reschedule pending
> alarms.)

I think this is a twofold problem:
1. The iPaq should be able to notify its environment about an alarm but
must hide personal information if the user is not logged on. 2. The
personal information as well as the fact that the alarm has expired
should be spooled for the user somehow so that the user gets a list of
missed alarms.

Number 2 is quite easy but number 1 is very unspecific...

> The tricky thing is the authentication, since an app running as a
> user needs to notify a daemon running as root to run an arbitrary
> app as that same user. The right way probably involves public-key
> cryptography, and my brain is starting to hurt.

This is ow security holes are born ;)
It is some time ago since I read this but I think you can get the user
ID out of out-of-band data after opening (accepting) the socket. I have
to check this again. But I have no idea how realiable/secure this is.
Does anyone know this in some more detail?

> Cheers,
> -j.
CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--