From owner-freebsd-fs Fri Jun 8 14:27:40 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id B65BB37B405; Fri, 8 Jun 2001 14:27:33 -0700 (PDT) (envelope-from pwd@apple.com) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id OAA05909; Fri, 8 Jun 2001 14:27:32 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 8 Jun 2001 14:25:46 +0100 Received: from thunder (thunder.apple.com [17.202.40.76]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id OAA23988; Fri, 8 Jun 2001 14:27:05 -0700 (PDT) Message-Id: <200106082127.OAA23988@scv1.apple.com> Date: Fri, 8 Jun 2001 14:27:04 -0700 From: Pat Dirks Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: Support for pivot_root-like system call? Cc: FreeBSD-Arch@freebsd.org, FreeBSD-FS@freebsd.org To: tlambert2@mindspring.com X-Mailer: Apple Mail (2.388) In-Reply-To: <3B2096AB.309B2D14@mindspring.com> Mime-Version: 1.0 (Apple Message framework v388) Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Friday, June 8, 2001, at 02:11 AM, Terry Lambert wrote: >> Prompted by the needs of, among others, virus protection software >> developers who want to be able to mount "on" the root directory to >> intercept ALL filesystem calls in the system, I'm contemplating >> implementation of a new system call in Mac OS X to do something like >> Linux's pivot_root system call: >> >> int pivot_root(const char *new_root, const char *put_old); >> >> (which basically installs "new_root" as the new "/" [root_vnode] in >> the system and transfers the current root directory to the pathname >> specified my "put_old") > > It doesn't work in FreeBSD proper because of cache coherency > bugs that have been around since 1995, but: > > mount -t nullfs / /put_old # or wherever > mount -t / > > Would do what you want, I think. True, that is the exact effect, except that it leaves the old root accessible only through a nullfs layer, which is unnecessarily ineffcient. > Really, the BSD way of doing this is to stack an FS with the > feature you want on top of the one without the feature in it. Oh, I know. The reason the developers are interested in this is for exactly that reason - in order to supplant "/" with a mount of their own so that they can layer their virus protection checks on the ordinary filesystem. They'd like to be able to implement a layered fileystem that'll cover the entire filesystem tree and which checks on various operations to make sure no viruses are being handled. Their antivirusfs_open code would, for instance, scan the underlying file before returning to the caller, forcing an error if a virus was detected. There are, I suppose, two aspects of pivot_root that are appealing: it provides a clean way to supplant all references to the existing 'rootvnode', not just in the kernel globals but in all running processes, and, in addition, it allows an atomic reorganization of the mount structure that can't be done with exactly the same effect in two separate operations because the old root will be inaccessible after the mounting of the new root. I see I missed a crucial bit in the checkdirs() code that's invoked after a mount where 'rootvnode' is automatically updated if something's mounted on "/". Considering that the main initial use for this call would actually be for the first reason above (merely supplanting "/"), not the second reason (moving where the current "/" appears) I think it'll be sufficient to adopt a bit more of the FreeBSD mount code to call checkdirs() after mount to update the existing processes in the system along with 'rootvnode'. If we find a call for pivot_root's more exotic restructuring functionality, we'll revisit the issue of implementing a new system call. Thanks for everyone's coments! -Pat Dirks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message