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