linux-kernel - Re: [PATCH] hfsplus: Remove hfsplus_file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Dec 2013 10:35:01 +0400
From:	Vyacheslav Dubeyko <slava@...eyko.com>
To:	Anton Altaparmakov <aia21@....ac.uk>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Sougata Santra <sougata@...era.com>,
	Christoph Hellwig <hch@...radead.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org Mailing List" 
	<linux-kernel@...r.kernel.org>, dri-devel@...ts.freedesktop.org,
	Szabolcs Szakacsits <szaka@...era.com>
Subject: Re: [PATCH] hfsplus: Remove hfsplus_file_lookup

On Wed, 2013-12-11 at 21:08 +0000, Anton Altaparmakov wrote:
> Hi,
> 
> On 11 Dec 2013, at 19:11, Al Viro <viro@...iv.linux.org.uk> wrote:
> > On Wed, Dec 11, 2013 at 10:49:29PM +0300, Vyacheslav Dubeyko wrote:
> >> This feature worked earlier under Linux. So, I suppose that some changes in HFS+ driver
> >> or in VFS broke it. And it needs to investigate and fix the reported issue. Thank you for the
> >> report.
> > 
> > This "feature" is severely broken and yes, outright removal is what I'd
> > suggest for a fix.  HFS+ allows hardlinks to files, which means that
> > you allow multiple dentries for the same inode with ->lookup() in it,
> > which is asking for deadlocks.
> > 
> > This is fundamentally not supported.  Considering that forks are lousy
> > idea in the first place, I'd seriously suggest to remove that idiocy for
> > good.
> 
> Completely agree with Al.  If anyone really wants access to forks they can implement them via the xattr interface (ok it has the 64k limitation but most forks are quite small so not much of an issue).  That's how I implemented access to named streams in Tuxera NTFS and it works a treat (and allows Linux apps and various security modules that require xattr support to work properly which is also great).
> 

Yes, I have the same considerations about using xattr way for the case
of resource fork after the night.

Usually, a file under HFS+ has or valid data fork, or valid resource
fork. So, HFS+ compressed file has valid resource fork only. Also alias
under Mac OS X has valid resource fork only. Of course, regular file can
have as valid data fork as valid resource fork. Fortunately, such case
is rare now (when file has both forks are valid). So, we can use xattr
way for accessing resource fork for such files. For example, it is
possible to use "osx.ResourceFork" xattr's name. And I suppose that 64
KB is reasonable limitation. Now we have access to FinderInfo fields of
CatalogFile's record for file under HFS+ by means of
"com.apple.FinderInfo" xattr.

I think that I can implement support of resource forks by means of xattr
way. Also, currently, I am implementing HFS+ compressed files support.
So, I can clean up old-fashioned way of resource forks support in HFS+
driver because of necessity to rework it anyway. The suggested patch
doesn't make all necessary cleanup, from my viewpoint.

Any comments?

Thanks,
Vyacheslav Dubeyko.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/