Michael Prokop <[email protected]> writes: > * Ferenc Wagner <[email protected]> [Mon Jun 14, 2010 at 12:47:42PM +0200]: >> 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 > > Ok thanks. > > Would be a "mount -o remount,newinstance /dev/pts" right after > mounting /dev/pts be an option for us? The command fails without > causing any problems if the required kernel option isn't set, so it > should be safe.
Probably yes. > Though AFAICS udev unmounts /dev/pts via /etc/init.d/udev anyway > (stating "we need to unmount /dev/pts/ and remount it later over the > tmpfs"). Should we ask the udev maintainer about it this issue as > well? Absolutely, I put Marco on Cc. Although I seem to recall sending him a note about this, I can't find any trace of it... We should really find a better place for this discussion, the current Cc list is somewhat stale. I changed the subject now. So, Marco, what do you think about this issue? -- Thanks, Feri. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
