Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!fafnir.la.locus.com!fafnir.la.locus.com!richard From: richard@locus.com (Richard M. Mathews) Newsgroups: comp.unix.internals Subject: Re: Ideas for changes to Unix filesystem Message-ID: Date: 8 Feb 91 23:35:02 GMT References: <1991Jan30.143326.16676@socs.uts.edu.au> <121494@uunet.UU.NET> Organization: Locus Computing Corporation, Los Angeles, California Lines: 29 bzs@world.std.com (Barry Shein) writes: >Since all flink() would do is enter a string/i-num pair into a >directory I can't see how any of this applies. >.... >But if it can be flink()'d at all then we assume you could seek to >zero and copy all the data out of the file to your own file anyhow, so >that's not a new opportunity. And whether you can read or write is >dictated by the setting of the inode and how the original fd was >opened which is independent of flink() entirely. Whether you can read or write is dictated by the mode setting of the inode and the effective uid/gid AND THE MODES OF THE DIRECTORIES YOU MUST PASS THROUGH TO GET TO THE FILE. All of this is deterimined AT THE TIME OF AN OPEN, and never again. By allowing creation of a link, you create an opportunity to do an open call which would otherwise have been prevented by the directory permissions. For example, say directory /user/joe/foo is mode 700 and file /user/joe/foo/bar is mode 666. Despite the mode of the file, I can't open it. If, however, a setuid-joe program lets me run a program I wrote while it has /user/joe/foo/bar open for read, then I can flink the file to /user/richard/gotcha which I can then open for write. Adding a restriction that you can do flink only if the file is open for write is an interesting idea. Richard M. Mathews Freedom for Lithuania richard@locus.com Laisve! lcc!richard@seas.ucla.edu ...!{uunet|ucla-se|turnkey}!lcc!richard