Re: again security proposal

Albert D. Cahalan (acahalan@cs.uml.edu)
Wed, 31 Dec 1997 23:22:45 -0500 (EST)


>> _CHECK_ permissions for files before make hardlink. If this
>> conflicts with some standards, maybe needed to make this
>> configurable.
>
> I'm sure it conflicts with quite a lot of standards, because
> it conflicts very fundamentally with the way UNIX handles
> files.

It is explicitly _allowed_ by the Unix98 standard.
It would be a very good default.

[that was important; junk follows]

> Is there nobody out there anymore that understands the beauty
> of the UNIX file systems, how the flat files are separated
> from the hierachical directory entries pointing to them. A
> file with just one link is as much "hard-linked" as a file
> with several links. An "N-link" file is no more a special
> case than a one-link file. Hard links are completely
> symmetrical. A file can even have zero links, in case a
> process holds it open after unlinking it.

That is some truly amazing brain damage. Traditional Unix even
allows hard links to directories. Directories are just flat
files anyway, right?

The whole inode concept is flawed. Modern tree-structured
filesystems like Reiserfs go through some terrible contortions
to emulate inodes.

Inodes are an implementation detail that someone foolishly
put into the standard API.

> I think one of the biggest mistakes in the history of UNIX was
> to call symbolic links "links". The word "pointer" would have

No, hard links should not have been in the API.