From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 23 23:17:10 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52593D3F for ; Tue, 23 Jul 2013 23:17:10 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from www.rawbandwidth.com (www.rawbandwidth.com [198.144.193.1]) by mx1.freebsd.org (Postfix) with ESMTP id 374B92BEA for ; Tue, 23 Jul 2013 23:17:09 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by www.rawbandwidth.com (8.14.4/8.14.4) with ESMTP id r6NNH2YZ009238 for ; Tue, 23 Jul 2013 16:17:02 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <51EF0EEE.8030000@rawbw.com> Date: Tue, 23 Jul 2013 16:17:02 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: FreeBSD Hackers Subject: Should process run under chroot(8) still see mounts on the original system? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:17:10 -0000 Currently, mount directories as shown by mount(8) command and /compat/linux/dev/mounts from linprocfs(5) still show the original mount points as other non-chrooted processes see. So, when some program run under chroot tries to read the mount points and do something with them it would likely fail because those paths aren't what the process actually sees in its file system. There are two situations: one when the process was started already chrooted (like with command chroot(8)), and another one is when process calls chroot(2) itself. Currently system seems to not differentiate between these two cases. It looks reasonable to automatically modify mount(8) and linprocfs(5) results when the process has been started already chrooted and this process is (practically) always unaware of chroot. So that when chroot was in place when execve(2), kernel could set the boolean flag and later adjust mount directories accordingly. I hit this issue while playing with GoogleTalk plugin (the linux app). I am running it in chroot environment, since it requires the higher linux libraries version than are currently installed on the host. It runs and connects to the browser plugin. But when it reads /compat/linux/dev/mounts in order to find /dev/shm (linux shm_open(3) function), it sees the wrong paths there and fails. It can't statfs the mount point. Yuri