linux-kernel - Re: [RFC 2/7] cramfs: create unique 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]

Date:	Sun, 1 Jun 2008 18:50:48 +0200
From:	Jörn Engel <joern@...fs.org>
To:	arnd@...db.de
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	hch@....de
Subject: Re: [RFC 2/7] cramfs: create unique inode numbers

On Sat, 31 May 2008 17:20:15 +0200, arnd@...db.de wrote:
> 
> This changes the inode number in cramfs to be based on
> the location of the dentry instead of the file, in order
> to make inodes unique.

Couldn't this cause problems for NFS?  The same inode no longer has a
stable inode number across reboots.  Basing on dentry location can also
be an information leak and cause problems on 64bit machines with old
userspace.

We could keep the original approach and use a static counter otherwise.
Something roughly like this:

static ino_t cramfs_get_ino(struct super_block *sb,
			struct cramfs_inode *cramfs_inode)
{
	static ino_t counter;
	struct inode *inode;

	if (cramfs_inode->offset && cramfs_inode->size)
		return cramfs_inode->offset << 2;

	for (;;) {
		counter++;
		if (!counter & 3)
			counter++; /* skip numbers that could be offsets */
		inode = cramfs_iget(sb, counter);
		if (!inode)
			return counter; /* free to use */
		iput(inode);
	}
}

> This lets us change and unlink files in a later patch
> without changing all other files that contain the same
> data, and it fixes a user-visible bug with 'cp -a'
> trying to hardlink empty directories when copying from
> a cramfs source.
> 
> A slight disadvantage is that identical files no longer
> share a common page cache, so the data has to be read
> from disk for each file individually.

That seems to be solved with above approach as well.

Jörn

-- 
You can take my soul, but not my lack of enthusiasm.
-- Wally
--
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/