* Ferenc Wagner <wferi@niif.hu> [Mon Jun 14, 2010 at 12:47:42PM +0200]: > 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 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. 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? regards, -mika-
Attachment:
signature.asc
Description: Digital signature