FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 06-14-2010, 05:36 PM
Ferenc Wagner
 
Default 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?
--
Thanks,
Feri.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87wru1jz3t.fsf_-_@tac.ki.iif.hu">http://lists.debian.org/87wru1jz3t.fsf_-_@tac.ki.iif.hu
 
Old 06-14-2010, 05:46 PM
 
Default Bug#501359: mount devpts with the newinstance option

On Jun 14, Ferenc Wagner <wferi@niif.hu> wrote:

> Michael Prokop <mika@debian.org> writes:

> > 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 .
Send patches to the initscripts maintainer.

--
ciao,
Marco
 
Old 06-14-2010, 06:15 PM
Ferenc Wagner
 
Default Bug#501359: mount devpts with the newinstance option

md@Linux.IT (Marco d'Itri) writes:

> On Jun 14, Ferenc Wagner <wferi@niif.hu> wrote:
>
>> 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?
>
> 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 debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ocfdjxat.fsf@tac.ki.iif.hu">http://lists.debian.org/87ocfdjxat.fsf@tac.ki.iif.hu
 
Old 06-14-2010, 06:22 PM
Petter Reinholdtsen
 
Default Bug#501359: mount devpts with the newinstance option

[Ferenc Wagner]
> 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!

Bug #584742 was about adding mkdir calls, and tat part is fixed. If
you want something new done, create a new bug report.

As for the mount options for /dev/pts/, I have no idea what it should
be, and have not had time to investigate it. We are seriously short
on man-power maintaining the sysvinit package, so help, feedback and
patches are needed to get fixes for the 300 open bugs added to the
package.

Happy hacking,
--
Petter Reinholdtsen



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100614182219.GA22952@login1.uio.no">http://lists.debian.org/20100614182219.GA22952@login1.uio.no
 

Thread Tools




All times are GMT. The time now is 12:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org