Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!inet-nntp-gw-1.us.oracle.com!news.caldera.com!news.cc.utah.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Date: 11 Feb 1996 23:56:19 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 48
Message-ID: <4flvn3$ivs@park.uvsc.edu>
References: <4er9hp$5ng@orb.direct.ca> <4f27sc$13a@dyson.iquest.net> <JRICHARD.96Feb9101113@paradise.zko.dec.com>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14189 comp.os.linux.development.system:17809
jrichard@paradise.zko.dec.com (John Richardson) wrote:
] > : mostly because it really turns out that BSD-style synchronous metadata
] > : updates are slow and buy you very little in terms of data safety, and
] > : can, in fact, be a security hole.
] >
] > whoa -- that's a big accusation for a filesystem that's been relied
] > on and worked on by a lot of people for a lot of time. what exactly
] > are you referring to? color me skeptical. (but willing to learn.)
]
] Since the metadata is written out before the actual data, if the
] machine crashes before data is written, the metadata may point to
] bogus data. This means you may have access to data that someone else
] thought was deleted.
Since the block allocation bitmap is updated *after* the data
blocks are updated, a crash with written inode metadata for a
file referring to previously used but not overwritten blocks
will result in the fsck removing the block references. This
works because the block allocation bitmap is synchronously
updated, and in the case of an interleved race on allocation
and deallocation, the bitmap update will be held pending the
metadata update for the deleted file. That is, there is no
situation where a block may be allocated in the bitmap, have
the previous data, and be referenced by a new inode.
This assumes you didn't intentionally break the ordering
assumptions in the fsck recovery sequence by bogusly hacking
the sources "to speed things up" without first understanding
the consequences.
Please refer to the paper "Fsck - The UNIX File System Check
Program" by Marshall Kirk McKusick of CSRG and T. J. Kowalski
of Bell Laboratories.
Security is one of the things you have to think about when you
are developing file system support software under joint grants
from the National Scientce Foundation and the Defense Advance
Research Projects Agency while being monitored by the Naval
Electronic System Command.
8-).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.