Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) | Date | Mon, 6 Feb 2006 16:13:39 +0100 |
| |
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@lists.sourceforge.net 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |