*BSD News Article 62563


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!floyd.sw.oz.au!usenet
From: jeremy@suede.sw.oz.au (Jeremy Fitzhardinge)
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Date: 21 Feb 1996 08:07:07 GMT
Organization: Softway Pty Ltd
Lines: 41
Message-ID: <4gejrb$ogj@floyd.sw.oz.au>
References: <4er9hp$5ng@orb.direct.ca> <4f9skh$2og@dyson.iquest.net>
  <4fg8fe$j9i@pell.pell.chi.il.us> <311C5EB4.2F1CF0FB@freebsd.org>
  <4fjodg$o8k@venger.snds.com> <4fo1tu$n31@news.jf.intel.com>
  <DMrCE4.3HF@pe1chl.ampr.org> <4ftjt9$fjs@park.uvsc.edu>
  <DMv8w7.8H4@pe1chl.ampr.org> <4g5ivp$28m@park.uvsc.edu>
NNTP-Posting-Host: suede.sw.oz.au
X-Newsreader: knews 0.9.3
In-Reply-To: <4g5ivp$28m@park.uvsc.edu>
To: Terry Lambert <terry@lambert.org>
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14677 comp.os.linux.development.system:18451

In article <4g5ivp$28m@park.uvsc.edu>,
	Terry Lambert <terry@lambert.org> writes:
>1)	Sync enhances the security of your files following a
>	crash and makes sure that part of one of your files
>	does not end up in someone elses hands.

Actually, I have direct evidence that this is not so (and since we like
throwing around proofs and proof-like language, take this as disproof
by counterexample).  On a Solaris 2.4/x86 system, I was involved in the
development of a device driver module.  As part of the load process,
you use a program which updates some files and loads the module.  In
this case, the load module was buggy and immediately crashed the system
on loading.  On reboot, the two files which were modified by the module
loader had their contents partially swapped.

Due to bogosities in Solaris kernel loading and module management,
these files are actually read by the kernel as it boots, so the
correctness of their contents is essential in order to boot.  The
corruption rendered the system unbootable and there was no chance that
fsck could be run.  On rebooting from a good root, fsck fixed the
corrupted filesystem structrure, but left the swapped contents.

The what-ifs:

- If the inodes had different owners, this would have been a security
  breach.

- If the filesystem had async metadata update, the files would
  be unaffected, since the metadata would have been updated with the
  contents but hadn't been at the time of the crash.

- If the module installer were written properly, it should have fully
  fsynced() the modified files (and preferably all filesystems) before
  loading possibly buggy kernel code (this is just a complaint about
  Solaris, and doesn't really have anything to do with filesystems).

Perhaps this is just an anti Solaris rant, and its filesystem is not
a current UFS implementation, but I doubt that.

	J