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

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > 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.
> 
> 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.

What about this (untested)?

BTW we do some playing with consoles after freeze. Would it be
possible to do it *before* freeze? Opening tty might change its
access time...?
							Pavel

Index: resume.c
===================================================================
RCS file: /cvsroot/suspend/suspend/resume.c,v
retrieving revision 1.4
diff -u -u -r1.4 resume.c
--- resume.c	3 Feb 2006 22:39:24 -0000	1.4
+++ resume.c	4 Feb 2006 19:19:48 -0000
@@ -227,6 +227,12 @@
 		error = errno;
 		goto Close;
 	}
+	/*
+	 * From now on, system is frozen; any filesystem access may mean data corruption.
+	 * Prevent accidental filesystem accesses by chrooting somewhere where little
+	 * damage can be done.
+	 */
+	chroot("/sys/power");
 	atomic_restore(dev);
 	unfreeze(dev);
 Close:
Index: suspend.c
===================================================================
RCS file: /cvsroot/suspend/suspend/suspend.c,v
retrieving revision 1.5
diff -u -u -r1.5 suspend.c
--- suspend.c	3 Feb 2006 22:39:24 -0000	1.5
+++ suspend.c	4 Feb 2006 19:19:51 -0000
@@ -360,6 +360,12 @@
 		goto Close;
 	}
 	go_to_console();
+	/*
+	 * From now on, system is frozen; any filesystem access may mean data corruption.
+	 * Prevent accidental filesystem accesses by chrooting somewhere where little
+	 * damage can be done.
+	 */
+	chroot("/sys/power");
 	attempts = 2;
 	do {
 		if (set_image_size(dev, image_size)) {


-- 
Thanks, Sharp!
-
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/