From owner-freebsd-security Sun Oct 28 11:52:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 6AF2637B403 for ; Sun, 28 Oct 2001 11:52:51 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id GAA24913; Mon, 29 Oct 2001 06:52:43 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01KA2BNZ174W2FHKTZ@cim.alcatel.com.au>; Mon, 29 Oct 2001 06:52:36 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f9SJqdj90800; Mon, 29 Oct 2001 06:52:39 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Mon, 29 Oct 2001 06:52:39 +1100 From: Peter Jeremy Subject: Re: recovery from 'rm -rf /' In-reply-to: <64563.1002193406@axl.seasidesoftware.co.za>; from sheldonh@starjuice.net on Thu, Oct 04, 2001 at 01:03:26PM +0200 To: Sheldon Hearn Cc: Martijn Lina , Thomas Beauchamp , freebsd-security@FreeBSD.ORG Mail-Followup-To: Sheldon Hearn , Martijn Lina , Thomas Beauchamp , freebsd-security@FreeBSD.ORG Message-id: <20011029065239.F75481@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20011003223038.G28329@medialab.lostboys.nl> <64563.1002193406@axl.seasidesoftware.co.za> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Oct 04, 2001 at 01:03:26PM +0200, Sheldon Hearn wrote: > > >On Wed, 03 Oct 2001 22:30:38 +0200, Martijn Lina wrote: > >> first of all, be sure that absolutely nothing is writing to the disk >> anymore. the inodes that have been freed last, will be the first to be >> used again. > >Are you sure about that? Prior to FFS, freed disk blocks went into a LIFO list so the last freed block would be the first allocated. A limited number (~100) of freed inodes are cached in the super-block (further freed inodes were just released). This means that new inodes would be allocated from roughly the 100 first deleted files in reverse order (additional inodes would be be allocated by searching the inode list for free inodes). With FFS, I'm not so certain. The following is based on a quick study of /sys/ufs/ffs/ffs_alloc.c - a FS guru might like to confirm it. The last freed inode may possibly be the first re-allocated inode (it's not immediately clear to me). Further inodes are allocated by a mixture of searching linearly through the free inode bitmap in a cylinder group and hashing between CGs. Likewise, the last release block may be cached, but further blocks are allocated by searching as before (potentially modified by rotational position). Soft-updates further confuses the issue - the dependency graph and write-behind means that the most-recently deleted file (blocks or inode) won't be available for immediate re-allocation. That said, avoiding writing anything to disk is good advice. If the other filesystems are clean and the mistake is noticed quickly, I'd even suggest using the reset button to avoid the sync-on-unmount (and not fsck'ing that filesystem after rebooting). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message