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
tanner@ki4pv.UUCP (Tanner Andrews) (12/18/85)
] utzoo!henry points out problem of fool opening/locking /etc/passwd
] and claims that adding open("arg", O_READ|EXCL) re-invents flock()
Doesn't re-invent flock() -- open()/flock() is not an atomic action.
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!tannergwyn@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.*
henry@utzoo.UUCP (Henry Spencer) (12/22/85)
> ] utzoo!henry points out problem of fool opening/locking /etc/passwd > ] and claims that adding open("arg", O_READ|EXCL) re-invents flock() > > Doesn't re-invent flock() -- open()/flock() is not an atomic action. Who cares if the open() succeeds, so long as the process doesn't do anything to the file until a successful flock()? The sequence is not atomic, but that doesn't matter. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jpl@allegra.UUCP (John P. Linderman) (01/04/86)
> 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
richl@lumiere.UUCP (Rick Lindsley) (01/08/86)
In article <7022@ki4pv.UUCP> tanner@ki4pv.UUCP (Tanner Andrews) writes: >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. Not true -- I may be doing a series of non-atomic reads, and I don't want things changing under me by another program writing in between my reads. That is where the shared lock comes in handy -- no need to disallow others from reading too, but if you want to write, you should get exclusive access. Rick Lindsley