Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

Hi,

On Monday 06 February 2006 00:02, Nigel Cunningham wrote:
> On Saturday 04 February 2006 23:51, Rafael J. Wysocki wrote:
> > On Saturday 04 February 2006 02:23, Pavel Machek wrote:
> > > On So 04-02-06 02:08:33, Olivier Galibert wrote:
> > > > On Sat, Feb 04, 2006 at 01:49:44AM +0100, Pavel Machek wrote:
> > > > > > Why don't you try to design the system so that the progress bar
> > > > > > can't fuck up the suspend unless they really, really want to? 
> > > > > > Instead of one where a forgotten open(O_CREAT) in a corner of
> > > > > > graphics code can randomly trash the filesystem through metadata
> > > > > > corruption?
> > > > >
> > > > > Even if I only put chrome code to userspace, open() would still be
> > > > > deadly. I could do something fancy with disallowing syscalls,
> > > >
> > > > Nah, simply chroot to an empty virtual filesystem (a tmpfs with max
> > > > size=0 will do) and they can't do any fs-related fuckup anymore. 
> > > > Just give them a fd through which request some specific resources
> > > > (framebuffer mmap essentially I would say) and exchange messages
> > > > with the suspend system (status, cancel, etc) and maybe log stderr
> > > > for debugging purposes and that's it.  They can't do damage by
> > > > mistake anymore.  They can always send signals to random pids, but
> > > > that's not called a mistake at that point.
> > > >
> > > > Even better, you can run _multiple_ processes that way, some for
> > > > compression/encryption, some for chrome, etc.
> > >
> > > No, I do not want to deal with multiple processes. Chrome code is not
> > > *as* evil as you paint it... But yes, chroot is a nice idea. Doing
> > > chroot into nowhere after freezing system will prevent most stupid
> > > mistakes. Rest of userland is frozen, so it can not do anything really
> > > wrong (at most you deadlock), if you kill someone -- well, that's only
> > > as dangerous as any other code running as root.
> >
> > I like the chroot idea too.
> 
> You're making this too complicated. Just require that the userspace program 
> does all it's file opening etc prior to telling kernelspace to do 
> anything. Then clearly document the requirement. If someone breaks the 
> rule, it is their problem, and their testing should show their 
> foolishness. We have done a similar thing in the Suspend2 userspace user 
> interface code, and it works fine.

Unfortunately I'd like to open at least one device file after freeze, for a
technical reason that probably does not exist in suspend2, so I need a
temporary filesystem anyway.  Chrooting to it is just a cake.

[BTW, we have the list suspend-devel@xxxxxxxxxxxxxxxxxxxxx we'd like
to be a place for discussing the userspace suspend issues.  If you could
subscribe to it, we'd be able to move the discussion there.]

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/