Re: [ 00/10] [Suspend2] Modules support.

[Olivier Galibert <galibert@pobox.com>]

On Fri, Feb 03, 2006 at 10:08:57PM +0100, Rafael J. Wysocki wrote:
> By the same token any code that's run as/by root is untrastable and it can
> destroy the system just as well.

Yes, and that's why old timers essentially never run GUI code as root.
The quality of that code tends to be... sloppy compared to the
standards of setuid code or kernel code.


> > That's exactly what I'm terribly afraid of.  You have no way to
> > enforce them, so they won't be respected.  And filesystems will die
> > randomly and unpredictably.
> 
> Yes, this may happen if the userland helpers are buggy, but again any
> root-equivalent process that is buggy can do the damage just as well.
> 
> Your point seem to be "we should implement this in the kernel to protect
> the users from irresponsible authors of userland applications
> and distributors".  I just don't agree with that.  [Going along this line of
> reasoning we should implement fsck in the kernel too. ;-)]

fsck isn't sexy and is implemented by the authors of the filesystems
or in close collaboration with them.  Even there, there is a lot of
talk about fscking live systems but nobody has dared it yet.  That has
some similarities with your situation.

There are two parts in your suspend userland helper.  The
functionality code, which you, and Pavel, and other highly competent
people will write.  I have no qualms with that one.  And then there is
the chrome code, the sexy code, that everybody and his dog is going to
want to muck with because that's where the looks are.  I'll give it 6
months at best from when you have a working system before you get a
submission for some themed, 3d-accelerated buzzword-compliant
nightmare of a progress bar.  With demented pressure to have it in the
official distribution because it looks like Babylon 5 on steroids.
Especially if you have a plugin structure, which otherwise makes a lot
of sense technically.  Will you be able to trust this code to do no
disk access and no other state changes that could be problematic (like
changing vt back to X)?

In other words, opening a window between the snapshot and the shutdown
for look-oriented code you won't control may not be a can of worms you
really want to have to handle.

While from the kernel side you can close the access to what you do not
want disturbed.

  OG.