Michael Prokop <[email protected]> writes: > * Ferenc Wagner <[email protected]> [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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
