Xref: utzoo comp.sys.att:5627 unix-pc.general:2311
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!cbmvax!ditto
From: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: Isn't it amazing what you find in the manuals?
Keywords: unixpc locking manuals security disruption
Message-ID: <6059@cbmvax.UUCP>
Date: 23 Feb 89 16:48:58 GMT
References: <481@uncle.UUCP> <6034@cbmvax.UUCP> <308@hsi86.hsi.UUCP>
Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Organization: Commodore Technology, West Chester, PA
Lines: 21

In article <308@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>In article <6034@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes:
>> I thought locking() only provided advisory locks.
>
>Unknown to most, and, of course, undocumented, is the fact that the
>3b1 (3.5.1 software) supports both advisory and mandatory locking.

That's the fcntl() locking your're talking about; we were talking about
the locking() system call.  fcntl() locking (what I called "real" SysV
locking in the above article) doesn't have the locking() security problem
because fcntl() only allows advisory locking unless the file owner marked
the file for mandatory locking, and to make a write lock you have to have
write permission.  You could, however, prevent a database from being
updated by putting a read lock on the whole thing.
-- 
					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ford@kenobi.cts.com
- The Unix Programmer's Manual,		...!sdcsvax!crash!kenobi!ford
  2nd Edition, June, 1972.		ditto@cbmvax.commodore.com