linux-ext4 - Re: Extended file stat: Splitting file- and fs-specific info?

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: <20120509042532.GO5091@dastard>
Date:	Wed, 9 May 2012 14:25:32 +1000
From:	Dave Chinner <david@...morbit.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	David Howells <dhowells@...hat.com>, adilger@...ger.ca,
	smfrench@...il.com, ben@...adent.org.uk,
	Trond.Myklebust@...app.com, roland@...k.frob.com,
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
	linux-ext4@...r.kernel.org, linux-api@...r.kernel.org,
	libc-alpha@...rceware.org
Subject: Re: Extended file stat: Splitting file- and fs-specific info?

On Tue, May 08, 2012 at 09:09:41PM -0400, J. Bruce Fields wrote:
> On Wed, May 09, 2012 at 10:24:20AM +1000, Dave Chinner wrote:
> > On Tue, May 08, 2012 at 09:19:42PM +0100, David Howells wrote:
> > > 
> > > Should I split the file-specific info and the fs-specific info and make the
> > > second optional?  What I'm thinking of is something like this:
> > > 
> > > Have a file information structure:
> > > 
> > > struct statx {
> > > 	/* 0x00 */
> > > 	uint32_t	st_mask;	/* What results were written */
> > > 	uint32_t	st_information;	/* Information about the file */
> > > 	uint16_t	st_mode;	/* File mode */
> > > 	uint16_t	__spare0[3];
> > > 	/* 0x10 */
> > > 	uint32_t	st_uid;		/* User ID of owner */
> > > 	uint32_t	st_gid;		/* Group ID of owner */
> > > 	uint32_t	st_nlink;	/* Number of hard links */
> > > 	uint32_t	st_blksize;	/* Optimal size for filesystem I/O */
> > > 	/* 0x20 */
> > > 	struct statx_dev st_rdev;	/* Device ID of special file */
> > > 	struct statx_dev st_dev;	/* ID of device containing file */
> > > 	/* 0x30 */
> > > 	int32_t		st_atime_ns;	/* Last access time (ns part) */
> > > 	int32_t		st_btime_ns;	/* File creation time (ns part) */
> > > 	int32_t		st_ctime_ns;	/* Last attribute change time (ns part) */
> > > 	int32_t		st_mtime_ns;	/* Last data modification time (ns part) */
> > > 	/* 0x40 */
> > > 	int64_t		st_atime;	/* Last access time */
> > > 	int64_t		st_btime;	/* File creation time */
> > > 	int64_t		st_ctime;	/* Last attribute change time */
> > > 	int64_t		st_mtime;	/* Last data modification time */
> > > 	/* 0x60 */
> > > 	uint64_t	st_ino;		/* Inode number */
> > > 	uint64_t	st_size;	/* File size */
> > > 	uint64_t	st_blocks;	/* Number of 512-byte blocks allocated */
> > > 	uint64_t	st_gen;		/* Inode generation number */
> > 
> > I don't think we want to expose the inode generation numbers. It is
> > trivial to construct NFS file handles (usually just fsid, inode
> > number and generation) with that information and hence bypass
> > security checks to access files.
> 
> I'm not convinced there's much value in trying to keep filehandles
> secret.

Sure, but I can't really see any good reason to expose filesystem
internal implementation details like this - a generation number is
usually used to differentiate between inode life cycles which
userspace has no concept of and is different for every filesystem,
so it's behaviour and values are not going to be consistent across
filesystems.  Some filesystems might not even have a generation
number they can export, and that makes me wonder if there is any
good reason for exposing it at all.

If you need to discriminate between versions of files with the same
name, then use name_to_handle_at() and compare filehandles....

Cheers,

Dave.

-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html