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!cbosgd!ihnp4!allegra!jpl
From: jpl@allegra.UUCP (John P. Linderman)
Newsgroups: net.bugs.4bsd,net.unix-wizards
Subject: Re: EXCL without CREAT
Message-ID: <5517@allegra.UUCP>
Date: Sun, 15-Dec-85 15:00:33 EST
Article-I.D.: allegra.5517
Posted: Sun Dec 15 15:00:33 1985
Date-Received: Tue, 17-Dec-85 04:25:16 EST
References: <5507@allegra.UUCP> <6220@utzoo.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 40
Xref: watmath net.bugs.4bsd:1884 net.unix-wizards:16120

> >	It is most unfortunate that open() flag O_EXCL only applies
> >	when O_CREAT is also in effect.  If there were a flag that
> >	meant ``succeed only if you can get me the file with nobody
> >	else having it opened, and nobody else able to open it,''
> >	then that atomic operation could have been used here.
> >	...Such a mechanism
> >	would save a lot of misguided hacking to achieve exclusive
> >	use of a resource.
> 
> It would also create problems of its own.  Consider the following:
> 	main() {
> 		int foo;
> 
> 		foo = open("/etc/passwd", O_READ|O_EXCL);
> 		for (;;)
> 			sleep(30000);
> 	}
> The CREAT-only restriction is there for a reason.
> 
> In any case, removing this limitation (assuming that the security problems
> could be solved) would amount to re-inventing flock(); why not just add an
> advisory/mandatory flag to flock()?

An excellent point, one I had overlooked.  A good example of why it is
well to throw ideas onto the net before throwing them into the kernel.
The answer to Henry's question is that flock is only effective among
``consenting processes''.  A process that doesn't use the protocol can
still scramble the output of those that do.  In the case of the line
printer software (and most other cases I can think of), the best
solution may be to make the device in question readable and writable
only by a user or group that can be assumed to be playing by the rules.

I can think of no use for TIOCEXCL, by the way, given the inevitable
window between the open and the ioctl.  Even consenting processes
cannot stay out of each other's way, and the ioctl does more harm than
good by suggesting that it might act as an effective lock.  Since
flock DOES provide an effective locking mechanism, at least among
consenting processes, TIOCEXCL should go away.

John P. Linderman  Department of Quick Reversals  allegra!jpl