rm etc. (was: Nasty Security Hole?)

[Nilbert T Bignum]

? From: Doug Gwyn  <gwyn at smoke.brl.mil>
? Date: 20 Nov 88 02:29:46 GMT

I'm a bit behind...

? The one extra wrinkle is that space used by an inode is reclaimed
? when it becomes totally inaccessible (last link to it is removed).
? All implementations of "symbolic links" that I know of are broken in
? this regard; even though symbolic links to an inode exist, the inode
? will vanish when all its "hard" links are removed (and the last open
? file table entry associated with it is closed).

I can think of places where this use might be desirable. Unfortunately,
`-llibname' doesn't look in `.', and the -L flag to ld is not universal.
A symlink in /usr/lib or /usr/local/lib to somewhere else is a way of
delegating authority to modify part of `the system' without giving
away any root privileges. Another example might be the X11 entrys in
/usr/{include,bin,lib}. And finally, some editors and other utilitys
rename the original file to the backup name and write a new version,
king hard links useless.

But you are lamenting the fact that symlinks are not ref counted.
If symlinks are `soft links', what you want is a `firm link' :-)
Firm links are symlinks that also bump the soft link ref count
field, which we also need to add to the inode. The kernel will
not reclaim an inode unless both ref counts are zero. An option
to unlink(2) can be added to decrement the soft count as well.

How about them feechurs!

	Nilbert T Bignum <rbj at nav.icst.nbs.gov>
	NTSI: Never Twice the Same Institute