Path: utzoo!utgpu!watserv1!watmath!att!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!ucsd!nosc!crash!nusdecs!rwhite
From: rwhite@nusdecs.uucp (0257014-Robert White(140))
Newsgroups: comp.unix.programmer
Subject: Re: Determining if an existant file is open
Message-ID: <1990Nov25.014317.11660@nusdecs.uucp>
Date: 25 Nov 90 01:43:17 GMT
References: <1990Nov16.200945.14468@nusdecs.uucp> <274975C4.21C@tct.uucp> <26251:Nov2119:42:1090@kramden.acf.nyu.edu>
Organization: National University San Diego
Lines: 62

In article <26251:Nov2119:42:1090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <274975C4.21C@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>> According to rwhite@nusdecs.uucp (0257014-Robert White(140)):
>> >Do the "put process number in lock file" thing as in uucp.
>> For you doubters: Once you've determined that a lock file is stale and
>> you want to unlink() it, how do you know the lock file hasn't been
>> replaced in between the decision to unlink() and the unlink() itself?
>The old name will never be reused, so there's no danger of replacement.

The above is (except for my comment) incorrect.  The application of the
basic rules of computer science reveals the following procedure:

Given:  A singular lock file name (multiple names is a waste of effort).
Given:  This file will have read-and-write access to all pertinant parties.
Given:  Complete File longevity (e.g. never remove it) can simplify the
	following but is not always desireable.
Given:	using fixed-width data simplifies internal manipulation.

Perform the following:
Serarch for and open file.
	If file is not found, create it.
	<At this point the "window of vulnerablility exists>
	<as this is not yet the "lock" procedure.>
Lock the file for exclusive Access.
	<Once you own the lock on the file there is no chance of>
	<confilict durring lock validation.  The requestors will>
	<be FIFO(ed) by the locking mechanisim.  The active lock>
	<may in itself be enough for a given purpose, this would>
	<tie up a lock slot so it may be desireable to continue>
Recover the process ID of the current locking process.
	If process is current, do nothing.
	Otherwise, replace process ID with this-process' ID.
Release Lock and close file.
Perform Actions of program.
Remove file.

Given that the ownership of the file is immeterial, since it is just
as easy to arbitrarily decide on universal writeability as it is to
decide on read and delete permissions, the "delete old file" step is
ineffective and tends to introduce unnecessary windows of vulnerability.

The use of the file lock keeps the above essentially atomic (as in
atomic operations like test-and-set) in its scope of operations.  
This trait means that the lock on the file, which is cleaned up on
program exit by the operating system in cases of abnormal exit, is
enough to garentee exclusivity;  the file lock state becomes a
semiphore (uesful for RFS environemnts where semiphores are not available
across the network link) and the access can be seezed and released 
by a pool of users without relying on PIDs.

There are a large number of really good variations on the above, each
of which is effective only so long as every program uses the mechanisim
every time.  But then again there is nothing you can really do along
these lines to protect yourself from rogue programs.

*******************************************************************
Robert C. White Jr.    |   Not some church, and not the state,
Network Administrator  |      Not some dark capricious fate.
National University    |   Who you are, and when you lose,
crash!nusdecs!rwhite   |      Comes only from the things you chose.
(619) 563-7140 (voice) |                             -- me.
*******************************************************************