From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: PROBLEM: hfsplus filesystem allows opendir() on plain files Date: Sat, 6 Dec 2008 22:31:33 +0000 Message-ID: <20081206223133.GR28946@ZenIV.linux.org.uk> References: <493553C0.2090407@frey.co.nz> <20081202222111.GA2738@cynthia.pants.nu> <20081205093948.GA15714@infradead.org> <20081206063226.GB13807@cynthia.pants.nu> <20081206064739.GN28946@ZenIV.linux.org.uk> <20081206072122.GC13807@cynthia.pants.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Damian Stewart , linux-fsdevel@vger.kernel.org To: Brad Boyer Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:58039 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752800AbYLFWbg (ORCPT ); Sat, 6 Dec 2008 17:31:36 -0500 Content-Disposition: inline In-Reply-To: <20081206072122.GC13807@cynthia.pants.nu> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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...