From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@ucw.cz>
Subject: Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
Date: Sat, 4 Feb 2006 20:57:44 +0100
User-Agent: KMail/1.9.1
Cc: Olivier Galibert <galibert@pobox.com>, linux-kernel@vger.kernel.org
References: <200602030918.07006.nigel@suspend2.net> <200602041451.45232.rjw@sisk.pl> <20060204192123.GB3909@elf.ucw.cz>
In-Reply-To: <20060204192123.GB3909@elf.ucw.cz>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200602042057.45369.rjw@sisk.pl>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3020
Lines: 85

Hi,

On Saturday 04 February 2006 20:21, Pavel Machek wrote:
> > > 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)?

So you think we should chroot from the user space.  Fine.

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

Yes, you are right, but please see below.

> 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");

We are on an initrd here. :-)

>  	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");

This won't be enough if /sys/power is on a frozen ext2 and the suspending
utility calls open("file", O_CREAT) "by accident".

I think we should do as Olivier said: Mount tmpfs with limited size somewhere
and chroot to it (IMO this won't affect the underlying filesystem).  Then, create
device files for the console and vt on it and open them from there.  This should
be 100% safe.

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/