lockf and the SVID, (Was "Re: Wanted: lockf system call source")

[Craig Jackson]

In article <2264 at sdcsvax.UCSD.EDU> hutch at 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 at sdcsvax.ucsd.edu


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