Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!panda!enmasse!drilex!dricej
From: dricej@drilex.UUCP (Craig Jackson)
Newsgroups: comp.unix.wizards
Subject: Re: lockf and the SVID, (Was "Re: Wanted: lockf system call source")
Message-ID: <191@drilex.UUCP>
Date: Tue, 2-Dec-86 08:46:26 EST
Article-I.D.: drilex.191
Posted: Tue Dec  2 08:46:26 1986
Date-Received: Tue, 2-Dec-86 20:29:20 EST
References: <5413@brl-smoke.ARPA> <2264@sdcsvax.UCSD.EDU>
Reply-To: dricej@drilex.UUCP (Craig Jackson)
Organization: Data Resources/McGraw-Hill, Lexington, MA
Lines: 37

In article <2264@sdcsvax.UCSD.EDU> hutch@sdcsvax.UUCP (Jim Hutchison) writes:
>Not that H-P is at fault for following the mighty SVID, but why require
>that the file-descriptor is open for write to do a write lock?  Wouldn't
>any open file-descriptor do?  

I think the idea is to ensure that the user has write permission for
the file descriptor.  A clean way to accomplish this is to require it
to be open for writing.

You want to require write permission for a write lock to prevent various
kinds of malicious denial-of-service.  Otherwise, someone on a low-permission
account might program the sequence:

   lock-the-file-for-writing;
   sleep(3600);
   unlock-the-file;

and lock all legitimate writers out for an hour or more at a time.

>I can see a reasonable scenario where a program reading a file might not
>want the record it is looking at changed under it.  This would seem pretty
>common when dealing with multiple processes accessing a database.  What
>gives?

There really should be several kinds of read locks: one that allows many
writers (pretty useless), one that allows a single writer, and one that
allows no writers at all.  I don't have a SVID, either, so I don't know
exactly what fcntl implements.

>    Jim Hutchison   UUCP:	{dcdwest,ucbvax}!sdcsvax!hutch
>		    ARPA:	Hutch@sdcsvax.ucsd.edu


-- 
Craig Jackson
UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej
BIX:  cjackson