Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices

[Ferenc Wagner <wferi@niif.hu>]

Michael Prokop <mika@debian.org> writes:

> * Ferenc Wagner <wferi@niif.hu> [Wed Jun 09, 2010 at 04:14:22PM +0200]:
>
>> A side note: a couple of lines later devpts is still mounted in "legacy"
>> mode.  This makes full devpts isolation impossible, which is a problem
>> if the running system wants to use Linux containers.  I didn't track,
>> maybe this devpts mount does not survive the initramfs phase, but if it
>> does, this issue is something to think about (until the devpts default
>> changes, which won't be soon, and surely not for 2.6.32).
>
> Sorry, I'm not sure I can follow you. Can you please elaborate a bit?

You may want to refer to Documentation/devpts.txt in the Linux kernel
tree for more details.  Above I mixed up the terminology somewhat.  The
Squeeze kernel has CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, so it isn't
running in legacy mode, but the devpts mounts (both in the initramfs and
in the startup scripts) don't use the 'newinstance' option, so the
system ends up using the "initial kernel mount of devpts".  Now even if
the container setup scripts take care to mount their own devpts
instances using the 'newinstance' option, this does not forbit the
contained system to also mount the "initial kernel mount of devpts" and
possibly interfere with the host system through it.  The solution is to
mount devpts in the host system with the 'newinstance' option, too, and
thus insulate it from the containers possibly running on the host.

I'm still disturbed by the fact that several containers could mount the
"initial kernel mount of devpts" and cooperate through it, but that's
their choice to use the inherently insecure common instance.

Hope I managed to make it clearer now.  I'm no expert of this, but this
concern seems somewhat founded, cf.
http://article.gmane.org/gmane.linux.kernel.containers.lxc.devel/298
-- 
Thanks,
Feri.