Ideas for changes to Unix filesystem

[Barry Shein]

From: xtdn at levels.sait.edu.au
>bzs at world.std.com (Barry Shein) writes:
>> 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.
>
>Copying a file now gives access to the current contents later.  Flinking
>a file now could give access to the future contents of that file.  This
>may not be desirable.  It is, however, unlikely to be a major problem to
>the aware programmer: an appropriate file mode solves all!

Ok, granted, if the path to the original file was not accessible and
was opened by a priv'd program and the fd handed down (e.g. thru an
open(), setuid() and then an exec()), then an flink() would bypass the
original directory protection. Thus, an accessible file in an
inaccessible directory would become accessible. If it were a changing
file it could then be opened any time later, even long after the
program exited, w/o need for the original priv. Whew.

So you're right, that *is* a potential problem. And just subtle enough
that it might bite someone in a big way.

Just thought I'd lay that out before we got a hundred "huh?" messages.

I'd say that pretty much condemns flink() as an idea unless someone
can think of a way around that. I can't think of anything that's not
awful.
-- 
        -Barry Shein

Software Tool & Die    | bzs at world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD