Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!levels!xtdn From: xtdn@levels.sait.edu.au Newsgroups: comp.unix.internals Subject: Re: Ideas for changes to Unix filesystem Message-ID: <15892.27bb2440@levels.sait.edu.au> Date: 14 Feb 91 23:58:56 GMT References: <15878.27b3841d@levels.sait.edu.au> <27B98C54.66F9@tct.uucp> Organization: University of South Australia Lines: 23 chip@tct.uucp (Chip Salzenberg) writes: > What if flink() were permitted only on file descriptors open for > O_RDWR without O_APPEND? After all, if you have a file descriptor > meeting that description, there's almost nothing bad you can do with > the file that you couldn't do with the file descriptor, slower. I think we've already discussed that, in time, the file contents could be changed: Just because we're allowed to read the file now doesn't mean that we should be allowed to read the future contents. Never the less I like the idea of flink() and I don't see much benefit in discussions along the lines of "only allow flink() on fd's open for O_xxx". Sorry to stifle this thread, people, but I believe that we can say little more than: flink() does have some security implications that one must be aware of, but being aware of them probably goes most of the way to circumventing those problems. Enough said? David Newall, who no longer works Phone: +61 8 344 2008 for SA Institute of Technology E-mail: xtdn@lux.sait.edu.au "Life is uncertain: Eat dessert first"