linux-kernel - Re: [PATCH v2 1/5] fat: allocate persistent inode numbers

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: <20120904161747.GJ23464@ZenIV.linux.org.uk>
Date:	Tue, 4 Sep 2012 17:17:47 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Namjae Jeon <linkinjeon@...il.com>
Cc:	hirofumi@...l.parknet.co.jp, akpm@...ux-foundation.org,
	bfields@...ldses.org, linux-kernel@...r.kernel.org,
	Namjae Jeon <namjae.jeon@...sung.com>,
	Ravishankar N <ravi.n1@...sung.com>,
	Amit Sahrawat <a.sahrawat@...sung.com>
Subject: Re: [PATCH v2 1/5] fat: allocate persistent inode numbers

On Wed, Sep 05, 2012 at 12:57:44AM +0900, Namjae Jeon wrote:
> From: Namjae Jeon <namjae.jeon@...sung.com>
> 
> All the files on a FAT partition have an on-disk directory entry.
> The location of these entries, i_pos, is unique and is constructed by the
> fat_make_i_pos() function.We can use this as the inode number making it
> peristent across remounts.

> --- a/fs/fat/namei_vfat.c
> +++ b/fs/fat/namei_vfat.c
> @@ -954,6 +954,8 @@ static int vfat_rename(struct inode *old_dir, struct dentry *old_dentry,
>  	new_dir->i_version++;
>  
>  	fat_detach(old_inode);
> +	if (MSDOS_SB(sb)->options.nfs)
> +		old_inode->i_ino = new_i_pos;

Sigh...  Inode numbers are reported by fstat() in stat.st_ino.  They must
	* remain constant from open() to close(), even if file gets
unlinked or renamed.
	* be equal for two simultaneously opened descriptors with the same
st_dev *ONLY* if those descriptors refer to the same file (i.e. if writing
through one of those would change the data read through another, etc.)

And yes, the userland code does depend on those properties.  There's a damn
good reason why we had gone for all those convolutions with separate hash,
etc.

inode->i_ino on a live struct inode is _never_ changed.  Period.
--
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/