Enhanced Upstart User Sessions for the Raring desktop

[Steve Langasek]

[including upstart-devel and ubuntu-devel both on this thread, instead of
having two separate discussions.]

On Tue, Nov 20, 2012 at 10:18:50AM -0800, Kees Cook wrote:

> >> This would mean user jobs would not be able to react to system job
> >> events.  That in itself might not be a problem [1], but it would also
> >> mean that user jobs have no access to system events (by default) that
> >> don't relate to jobs.  I think this _is_ potentially more of an issue. 
> >> My canonical example is being able to plug a USB headset in, and have a
> >> user job react to the udev event and start an application of my choice. 
> >> This currently works if user jobs are enabled in Ubuntu and is a useful
> >> feature.  If we did implement ':all:', we could change the
> >> upstart-udev-bridge to ensure it emits events to ':all:', but we're
> >> then back to the concern over permissiveness and it feels wrong to
> >> special-case one particular event source.

> > I don't think this is a bad solution - users need access to device events
> > (and effectively already have them anyways) so it makes sense for
> > upstart-udev-bridge to emit public events. It's just a question whether it
> > does so explicitly or implicitly.

> I like the idea of it needing to explicitly send such events. The
> down-side is that perhaps that means suddenly all events will just be
> written by their authors to explicitly use ":all:", and then this
> design choice wasn't useful. That said, it seems like making user
> session "omniscient" is asking for trouble.

I think
<https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036157.html>
addresses this.  No, upstart events are not echoed to the dbus system bus,
but the content of these events is such that most of them can be divined
with only moderate difficulty:  hardware events will have corresponding
uevents, and service start/stop events can be polled with the 'status'
command.

So I'm strongly +1 for not trying to hide system-level events from user
jobs.

> > The case that originally came to mind was some sort of system audit or
> > scan.  If my system does an anti-virus scan, I don't want potential
> > userspace malware to receive a nice convenient event notification that
> > they should quiesce until the scan is finished (and then another
> > notification to wake back up again once the scan completes).

> Or maybe malware could use events to improve timing attacks against
> system services ("oh, it's starting, move those files around to
> confuse it!").

Those are interesting hypotheticals, but I don't think they should drive the
design.  AFAICS there's nothing here that's new vs. dbus.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20121121/0d19d0a4/attachment.pgp>