linux-kernel - Re: 2.6.29 -mm merge plans

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]

Message-ID: <Pine.LNX.4.64.0901120442280.28002@localhost.localdomain>
Date:	Mon, 12 Jan 2009 05:21:39 +0100 (CET)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	"Diego E. 'Flameeyes' PettenÃ²" 
	<flameeyes@...il.com>
cc:	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Warren Turkal <wt@...guintechs.org>
Subject: Re: 2.6.29 -mm merge plans

Hi,

On Wed, 7 Jan 2009, Diego E. 'Flameeyes' Pettenò wrote:

> Yes that one wasn't good at all, and I feel sorry for not having noticed
> that before sending it in the first place.

In general you could also use the create_date field to initialize the 
generation field (it's set in hfsplus_cat_build_record and should be read 
in hfsplus_cat_read_inode). (BTW OS X doesn't use create_date because it 
can be changed by the user, which isn't an issue for Linux).
I have some doubts about the hfsplus_get_parent() function. One has to 
know about HFS+ that every hard link has it's own link id (which is 
usually not visible) and the common inode id. If you lookup the parent 
like this you expose the usually hidden and private directory.
The link id is stored in d_fsdata under Linux, which seems not to be 
restored by hfsplus_fh_to_dentry(), so any catalog manipulations are 
likely to hit the wrong catalog entry. Any catalog change requires the 
correct link id, but with just the common id you currently can't find back 
the link entry.
Newer HFS+ OS X driver support a link chain, which would make it possible 
to find back the link entry using the common id and create_date in case 
the normal file became a hard link, but this isn't implemented under Linux 
yet.
So it seems the hard link handling may need a bit more work...

bye, Roman