Path: utzoo!utgpu!watmath!att!rutgers!ucsd!usc!cs.utexas.edu!rice!uw-beaver!Teknowledge.COM!polya!ali
From: ali@polya.Stanford.EDU (Ali T. Ozer)
Newsgroups: comp.sys.next
Subject: Re: kernel corruption on 330Mb hd???
Message-ID: <12840@polya.Stanford.EDU>
Date: 17 Nov 89 02:12:52 GMT
References: <17504@kuhub.cc.ukans.edu> <5604@umd5.umd.edu> <12811@polya.Stanford.EDU> <12837@polya.Stanford.EDU> <5631@umd5.umd.edu>
Reply-To: ali@Polya.Stanford.EDU (Ali T. Ozer)
Organization: .
Lines: 29

In article <5631@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes:
>In article <12837@polya.Stanford.EDU> I wrote:
>>The bug has been discovered and there is a workaround ...
>>The problem occurs if you try to launch an executable in the Mach preload
>>format; depending on how the pages our laid out in the file, a part of the
>>file might become corrupted if paging occurs after the file is "launched."
>
>The files /sdmach and /odmach (which are the same file) are owned by root
>and their permissions are 555 -- readable and executable by all, writable by
>none.  How is it that the file can be written to when it is executed by a
>user other than root?

This is a bug, after all --- and bugs break rules.  

The bug will only occur if you try to execute a preload format file, and even 
then only under special circumstances, which the sdmach file exhibits. 
This bug will not occur when executing normal demand-paged executables or
trying to execute other non-executable files.  

Again --- this is not a file system bug but rather a bug in the program loader
trying to load a preload format file.  sdmach is the only file in the system
that will cause this bug to occur.

>If someone has a NeXT and does not have USENET access, how will they find
>out about the fix?

NeXT is getting the news out to customers through various other channels.

Ali