[email protected] (Marco d'Itri) writes: > On Jun 14, Ferenc Wagner <[email protected]> wrote: > >> 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? > > It's not really hard to check the init script. /dev/pts/ and /dev/shm/ > are mounted by /etc/init.d/mountkernfs.sh .
You mean /etc/init.d/mountdevsubfs.sh . > Send patches to the initscripts maintainer. That's why didn't find this stuff: because I mentioned it instead to the initscripts maintainer in Bug#584742. That bug was meanwhile closed, let's ask Petter about it again! Besides that, I still think fixing this in the initramfs would be a good idea, just in case something goes wrong or changes later. -- Thanks, Feri. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
