From owner-freebsd-arch@freebsd.org Sun May 15 16:53:37 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D384CB3C990; Sun, 15 May 2016 16:53:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DEA9120F; Sun, 15 May 2016 16:53:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id e201so13358314wme.2; Sun, 15 May 2016 09:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Y1hB2QtQw86g5Esi718zi9W2Rdhm8nQI48Gzl+oxQLo=; b=fXlhRU7dtzRsrz0aQqMjrJsYvzPVwaMBFS7+rbJgQjGr2ckEKqn6bZF6XcdC9abSIl OJYE+NvQkHc2C80ziEdPrOHABDXweIN7oCMgKrTGufI/emJ4Qe2Tk64vb+KmjqqS2JDG I4eREXCsZP3kvcPbIspl5+F4fx2cdX4E1NnLAi1mKmiCvb++mkpv4WUAAiuVOlnoOh7j 15mXgYkSmCbwz43F9RvfOJFznvSSSZycGZhrO+WbCEZkVdwPE6X7BdfBoQVMititnuZR /mffZVtKvCMzaaUJ7aakyzC3AL+9yllMeshI4w2TQMasoQRxJCCaoSKJ48WoIHQMKKxW EVJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Y1hB2QtQw86g5Esi718zi9W2Rdhm8nQI48Gzl+oxQLo=; b=EPMHiYsTPvh0DqxUHK+GNfKGps0OOVSfjjXDbj5Kza9LPBhGBLzxAWCa7pI2WtEJuH HO/THMTsBJB2KFfqLitdCZyXiufpmtpRWZmoXrIOJXqH2XwPqH7EC8/xpNihABPfUosZ itfN3bdhwdrEvDdV6+z3DKizDdcB9ISoXZBmRVglyJxiPUMpv0c262NlCwuNboIZQrs9 XPr4Kaqs7DiWX7bzO4UgDyEEGUg9ZW323u0SaxcZTbaY+EWnsn9TH5W39SKvi/TYgBHV 6DqWwaYfa7Obttb7MA64PQf2QG4FvRFd2I5fvRiAp3/Z1v2H/S+KUtZhD2QKE97RKhI0 9umg== X-Gm-Message-State: AOPr4FVvul2R3LpF1VutAwX2UMkvpoR32Rpyqxsf02LnkAOkwHQm9YYzEcLL84Pgom9tVQ== X-Received: by 10.194.234.167 with SMTP id uf7mr25495264wjc.122.1463331216058; Sun, 15 May 2016 09:53:36 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id c194sm13990641wme.9.2016.05.15.09.53.34 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 15 May 2016 09:53:34 -0700 (PDT) Date: Sun, 15 May 2016 18:53:32 +0200 From: Mateusz Guzik To: Andriy Gapon Cc: freebsd-arch@FreeBSD.org, freebsd-fs Subject: Re: mount / unmount and mountcheckdirs() Message-ID: <20160515165332.GA27836@dft-labs.eu> References: <5c01bf62-b7b2-2e1d-bca5-859e6bf1f0e5@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5c01bf62-b7b2-2e1d-bca5-859e6bf1f0e5@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 16:53:37 -0000 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. 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. That said, this likely needs to be simply changed to /deny/ mount operations which would alter jail roots. -- Mateusz Guzik