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

[Nigel Cunningham <ncunningham@cyclades.com>]

Hi.

On Saturday 04 February 2006 23:51, Rafael J. Wysocki wrote:
> Hi,
>
> 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.

Regards,

Nigel

> Are we going to chroot from the kernel level (eg. the atomic snapshot
> ioctl()) or from within the suspending utility?
>
> I think the kernel level would protect some people from bugs in their
> own suspending utilities, but then we'd have to mount the tmpfs from the
> kernel level as well.
>
> Greetings,
> Rafael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Attachment: pgpDiYlIsaUic.pgp
Description: PGP signature