Should process run under chroot(8) still see mounts on the original system?

Teske, Devin Devin.Teske at fisglobal.com
Tue Jul 23 23:44:53 UTC 2013


On Jul 23, 2013, at 4:31 PM, Mateusz Guzik wrote:

> On Tue, Jul 23, 2013 at 04:17:02PM -0700, Yuri wrote:
>> 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.
>> 
> 
> While changing the code to do what you propose would not be that
> difficult, I don't see the point. In cases like this you can simply
> jail(2) and there you go (or at least this should work just fine).
> 
> Of course then you may have some unnecessary separation but that I
> believe can be simply worked out if it turns out to be problematic.
> 

What the OP wants is implemented for jails via the sysctl ``knob'' "security.jail.enforce_statfs"

It can have one of three values.

0 = show nothing from the base in jailed df(1) output
2 = show everything from the base in jailed df(1) output

What you want sounds like the number in-between:

1 = show only mount points from the base that appear within the jail *and* make the jailed df(1) output show a modified path that is rooted in said jail
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.


More information about the freebsd-hackers mailing list