Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!sri-unix!hplabs!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: Which commands (in /bin & /usr/bin) must have set user ID (for root)
Message-ID: <8545@sun.uucp>
Date: Sun, 26-Oct-86 04:16:35 EST
Article-I.D.: sun.8545
Posted: Sun Oct 26 04:16:35 1986
Date-Received: Mon, 27-Oct-86 01:42:49 EST
References: <115@tijc02.UUCP> <735@hropus.UUCP> <1040@ho95e.UUCP> <1269@ttrdc.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 42

> Waitaminnit... at least on SysV, it is not possible to overwrite, or
> remove the last link to, any executable file which is currently being
> run (this doesn't count shell scripts).   I do not know whether BSD has
> the same restriction.

BSD has the former restriction, but not the latter.

> Could someone suggest a reason for this (other than security)...

There is no good reason whatsoever for the latter restriction, which is why
Berkeley lifted it.  Since the shared text structure (or, presumably, the
region structure in later S5 implementations) holds on to the inode, the
file doesn't really disappear when unlinked (although there are no directory
entries referring to it) until the last process releases that shared text.

The only reason I've heard was something on the order of "well, if you have
the system holding on to one of these 'no directory entries point to it'
files, and the system crashes, it shows up as an unreferenced file", which
is boguus because 1) the exact same thing happens if you remove the last
link to a file which somebody has open, and UNIX doesn't forbid that, and 2)
"fsck" will clean up those unreferenced files anyway.

There are better reasons for the former restriction.  In an unpaged system,
if you wrote to the file the change would not necessarily be reflected in
the copy in main memory or on the swap device; as such, until those copies
last their last reference and disappeared, processes trying to execute that
file would get a copy of the old text and a copy of the new data, which
would be very confusing.  In a paged system, it's even worse - processes
currently using that file could get a mixture of old and new pages!

In a system using NFS, it is impossible to prevent a file from being opened
for writing by a process on one machine if another machine is using that
file as a shared text (because it's impossible for the machine on which the
file resides to find out who's holding on to it), so the writes are allowed
to go through; however, if the process using that file tries to fetch a
page from a file that has been modified since the process in question first
attached to it, it gets zapped by a SIGKILL (a message is printed on the
user's terminal, if there's a terminal associated with this process).
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)