Date: Thu, 14 Sep 2017 15:58:13 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Mateusz Guzik <mjguzik@gmail.com> Cc: freebsd-arch@FreeBSD.org, freebsd-fs <freebsd-fs@FreeBSD.org> Subject: Re: mount / unmount and mountcheckdirs() Message-ID: <69d80f6d-da25-7b94-7774-564cecd0a8c2@FreeBSD.org> In-Reply-To: <20160515165332.GA27836@dft-labs.eu> References: <5c01bf62-b7b2-2e1d-bca5-859e6bf1f0e5@FreeBSD.org> <20160515165332.GA27836@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15/05/2016 19:53, Mateusz Guzik wrote: > On Sun, May 15, 2016 at 04:37:05PM +0300, Andriy Gapon wrote: >> >> I am curious about the purpose of mountcheckdirs() called when mounting and >> unmounting a filesystem. >> >> The function is described as such: >> /* >> * Scan all active processes and prisons to see if any of them have a current >> * or root directory of `olddp'. If so, replace them with the new mount point. >> */ >> and it seems to be used to "lift" processes and jails to a root of a new >> filesystem when it is mounted and to "lower" them onto a covered vnode (if any) >> when a filesystem is unmounted. >> >> What's the purpose of those actions? >> It's strange that the machinations are done at all, but it is stranger that they >> are applied only to processes and jails at exactly a covered vnode and a root >> vnode. Anything below in a filesystem's tree is left alone. Is there anything >> so very special about being at exactly those points? >> >> IMO, the machinations can have unexpected security consequences. >> > > I don't know why this was implemented. It is also being done in NetBSD. > It is not done in Solaris nor Linux. I've done some testing on illumos and while it indeed does not do any "lifting", it does not permit to mount over a directory which is a current directory for any process. I haven't tested with zones, but suspect that it would also be prohibited. > Replacement is buggy in at least 2 ways: > 1. the process vs jail vnode replacement leaves a time window where > these 2 don't match, which screws up with the look up > 2. on fork we can have a 'struct filedesc' object copied but not > assigned to the new process yet, so it ends up with the old vnode > > And indeed, interested parties still have access to old vnodes by means > of having a file descriptor. Yeah. > That said, this likely needs to be simply changed to /deny/ mount > operations which would alter jail roots. That's probably what we should do. Or rather, Someone Should Do It. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69d80f6d-da25-7b94-7774-564cecd0a8c2>