Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.internals Subject: Re: Ideas for changes to Unix filesystem Message-ID: Date: 14 Feb 91 09:24:59 GMT References: <15878.27b3841d@levels.sait.edu.au> <27B98C54.66F9@tct.uucp> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 25 In-Reply-To: chip@tct.uucp's message of 13 Feb 91 18:58:28 GMT >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. Except now you can come back later, say a week later, and re-open the file (assuming the file protexns were ok), without the setuid program. So there would be no point at which an applications writer or admin could be sure that no one could open that file (w/o checking links and searching the file system.) As a more concrete example, let's say the program which let you in used a list of valid users, and you were removed from that list. If you flink()'d it, you could still get at it. Another way of putting it is, if we allow flink(), how do we ever have a file which cannot be flink()'d, you'd need to invent a new bit for open() I guess. I suppose if you had such a bit one could argue that it's up to the application writer to set it (or unset it) if s/he cares. Perhaps it should be off (disallowed) by default. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD