linux-kernel - Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

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: <7963.1462869823@warthog.procyon.org.uk>
Date:	Tue, 10 May 2016 09:43:43 +0100
From:	David Howells <dhowells@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	dhowells@...hat.com, linux-fsdevel@...r.kernel.org,
	linux-afs@...ts.infradead.org, linux-nfs@...r.kernel.org,
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

Christoph Hellwig <hch@...radead.org> wrote:

> All of these are easily available.  But why special case them so that
> userspace must not ask for them?  This makes an otherwise totally
> regular interface special now.  Note that filesystems could always fill
> it out anyway and set it in the return mask.

Because it would be a waste of bits in the mask.  Is there a point in having
bits that are always going to be set unconditionally when we can just
*document* that these few fields are always going to be set.

I'm sure people can cope with the concept that some data are provided
unconditionally and don't have bits and the rest are provided conditionally
and do have bits.

I admit, though, that i_mode is tricky, since it's actually the combination of
two pieces of information - one conditional (permission bits) and one normally
unconditional (file type).  Possibly then i_mode should have two flags since I
can think of situations where the file type might be other - reparse points,
automount points.

So yes, you can look on it as there are special cases.  However, if I can drop
stat emulation support, everything resolves down to the following classes:

 (1) Stuff that's unconditional: st_dev, st_blksize, st_information (maybe).

 (2) st_mode & S_IFMT.  Unconditional or conditional?  I'm not sure.

 (3) Stuff that's conditional: st_mode & ~S_IFMT, st_rdev, st_ino, ...
     Basically everything else.

David