Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site allegra.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!jpl
From: jpl@allegra.UUCP (John P. Linderman)
Newsgroups: net.bugs.4bsd
Subject: Re: EXCL without CREAT
Message-ID: <5602@allegra.UUCP>
Date: Fri, 3-Jan-86 17:37:31 EST
Article-I.D.: allegra.5602
Posted: Fri Jan  3 17:37:31 1986
Date-Received: Sat, 4-Jan-86 05:48:03 EST
References: <5507@allegra.UUCP>, <6220@utzoo.UUCP> <7022@ki4pv.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 31

> Security is easily solved by refusing to allow locking a file unless
> the file has been successfully opened for WRITE -- there's no real
> excuse for a read-only prog to need to lock a file if the write-file
> prog successfully locks the damned thing anyway.
> -- 
> <std dsclm, copies upon request>	   Tanner Andrews, KI4PV
> uucp:					...!decvax!ucf-cs!ki4pv!tanner

I was thinking along the same lines until /dev/null came to mind.  It
has to be universally writable, and you dare not allow one process to
block all the others that may want to open it, or cause the opens to
fail.  Permissions alone aren't adequate to determine when it's ok to
block other processes.  They look reasonable for tty lines, they
clearly aren't for /dev/null.

This isn't a trivial problem, but I'll offer a few claims that I
haven't seen disputed (yet):

1) There is a genuine need for a mechanism to grant exclusive access
   to tty lines, at least among ordinary (unsuper) users.
2) flock is not such a mechanism, because processes can do opens
   without doing flocks.
3) The TIOCEXCL ioctl is not such a mechanism, because it isn't
   atomic.

My candidate for best solution therefore remains EXCL on the open,
with the effect left up to the driver.  Tty drivers can honor it,
the /dev/null driver can't, and maybe something semi-intelligent
can be done for ordinary files based on permissions.

John P. Linderman  Tender of flocks  allegra!jpl