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

From: Pavel Machek
Date: Sat Feb 04 2006 - 15:13:49 EST


Hi!

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

Yes, sorry that I was not explicit.

> > }
> > + /*
> > + * 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. :-)

Oops, right, forget that.

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

...well, we rely on sysfs files to work... at least for
suspend-to-RAM, ok, no argument here. I doubt anyone really does mount
anything but sysfs on /sys...

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

Looks unneccessarily complex to me. We'd have to umount that tmpfs,
and playing with mounts inside system suspend seems wrong to me.

Perhaps we can chroot into /proc... almost everyone has /proc
mounted, right?

Is it possible to move console/vt open before freeze? That should be
enough.
Pavel
--
Thanks, Sharp!
-
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/