[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#501359: mount devpts with the newinstance option

Michael Prokop <mika@debian.org> writes:

> * 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.

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?

Reply to: