Date: Tue, 23 Jul 2013 16:17:02 -0700 From: Yuri <yuri@rawbw.com> To: FreeBSD Hackers <hackers@freebsd.org> Subject: Should process run under chroot(8) still see mounts on the original system? Message-ID: <51EF0EEE.8030000@rawbw.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51EF0EEE.8030000>