henry@utzoo.UUCP (Henry Spencer) (12/12/85)
> 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()?
jpl@allegra.UUCP (John P. Linderman) (12/15/85)
> > 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
stephen@dcl-cs.UUCP (Stephen J. Muir) (12/17/85)
In article <5517@allegra.UUCP> jpl@allegra.UUCP (John P. Linderman) writes: >I can think of no use for TIOCEXCL ... >... TIOCEXCL should go away. I *need* to use it. When I log in to my machine through another and type the command "download prog", it "cat"s the binary file into the machine. Needless to say, a broadcast message would screw this up and I wouldn't see it anyway. Using "mesg n" is useless as it doesn't stop super-user. -- UUCP: ...!seismo!mcvax!ukc!dcl-cs!stephen DARPA: stephen%comp.lancs.ac.uk@ucl-cs | Post: University of Lancaster, JANET: stephen@uk.ac.lancs.comp | Department of Computing, Phone: +44 524 65201 Ext. 4599 | Bailrigg, Lancaster, UK. Project:Alvey ECLIPSE Distribution | LA1 4YR
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/19/85)
> Using "mesg n" is useless as it doesn't stop super-user.
Ah, but it *OUGHT* to.ddl@tardis.UUCP (Dan Lanciani) (12/19/85)
As far as I know, TIOCEXCL doesn't stop root, either. I had actually considered changing this, but is it deep in every driver (at least in 2.9.) Dan Lanciani ddl@tardis.*