Re: PROBLEM: hfsplus filesystem allows opendir() on plain files

[Al Viro <viro@ZenIV.linux.org.uk>]

On Fri, Dec 05, 2008 at 11:21:22PM -0800, Brad Boyer wrote:

> Apple added hard links with osx. Back when I wrote hfsplus originally,
> there wasn't any such thing on HFS+ either. The support for the hack
> that added the appearance of hard links was added after I stopped
> maintaining the code. It's really just a matter of hiding the real
> file in a special place and putting stubs with special settings where
> all the links appear in the namespace. In all truth both HFS and HFS+
> are inherently incompatible with the very concept of a hard link or
> having a file still exist after removal. It's just a horrible hack
> that makes it look like it works.

Well...  That's not too unreasonably way to do them, actually - just
treat your hidden directory as real inode table.  The tricky part is
keeping i_ino stable through all that, but if it's done...

FWIW, fs/qnx4 uses a somewhat similar scheme, IIRC.

To make things workable you need
	* hidden directory that would never be reachable by syscalls
	* recognizable files that would contain references to names
in that directory
	* lookup that would normally lead to such file getting inode
of object in hidden directory
	* link(2) with target being *not* one of those would start with
moving target to hidden directory and creating such "link" file in its
place.  Then it would create a link file in source.  That, BTW, would have
interesting implications wrt locking - we'd need to modify target's parent,
which can get sucky.
	* unlink(2) with victim dentry not being a "link" file *and* being
busy would move the victim to hidden.  Otherwise it'd kill the victim
outright.
	* final iput() of file that'd been taken to hidden does deletion
of directory entry in hidden if i_nlink is 0.

The interesting part is locking - you need to deal with lookup vs. eviction
of link(2) target to hidden and with rename vs. the same thing.

> > Which is to say, this stuff *must* go.  In case of HFS it's obnoxious,
> > but not immediately letal.  In case of HFS+ it's an instant DoS.
> 
> Feel free. I disavowed any responsibility for this code years ago. And
> before anyone thinks of complaining, I'll point out that I wasn't the
> one that submitted hfsplus for inclusion in the kernel either.

Not blaming you...