linux-ext4 - 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]

Date:	Thu, 05 May 2016 09:56:58 +1000
From:	NeilBrown <nfbrown@...ell.com>
To:	David Howells <dhowells@...hat.com>, linux-fsdevel@...r.kernel.org
Cc:	linux-afs@...r.kernel.org, linux-nfs@...r.kernel.org,
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
	dhowells@...hat.com, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

On Fri, Apr 29 2016, David Howells wrote:

> Add a system call to make extended file information available, including
> file creation time, inode version and data version where available through
> the underlying filesystem.
>
>
> ========
> OVERVIEW
> ========

I think all this documentation is invaluable - thanks.
I would really like to see much of it in
    Documentation/filesystems/something.txt
rather than just in the commit log.

>
> The defined bits in the st_information field give local system data on a
> file, how it is accessed, where it is and what it does:

These bits form a channel for communication between the filesystem
developer and the application writer.  As such we should be sure that
channel actually communicates meaning...

>
> 	STATX_INFO_ENCRYPTED		File is encrypted
> 	STATX_INFO_TEMPORARY		File is temporary

What is "temporary"?  Is it a statement about quality of storage
technology (will be destroyed by reboot) or intention of creator
(created with O_TMPFILE) or something else?

> 	STATX_INFO_FABRICATED		File was made up by filesystem
> 	STATX_INFO_KERNEL_API		File is kernel API (eg: procfs/sysfs)

What is the difference between these two?  Both are synthesized by the
kernel.
Maybe the "KERNEL_API" is declared never to change its meaning, while the
fabricated one doesn't make a "stable API" promise?

What is the difference between fabricating a file from a bunch of blocks
spread over a storage device, and fabricating a file from a single field
in the super-block?

> 	STATX_INFO_REMOTE		File is remote

How far is "remote"?  Does Infiniband count?  Fibre channel?  iSCSI?
Is a file on a loop-back mounted NFS filesystem more remote than a
fibre-channel connection to the next town?

Or is this relative?  Within a filesystem there are "remote" files and
"non-remote" files and the distinction is filesystem-dependant??

> 	STATX_INFO_AUTOMOUNT		Dir is automount trigger
> 	STATX_INFO_AUTODIR		Dir provides unlisted automounts

I think this last one means that there are names in the directory which
may not appear in "readdir" but will respond to "stat".  I would prefer
the description to match the behavior without necessarily implying that
those names will be automounts.  e.g
        STATX_INFO_INCOMPLETE_READDIR   getdents may not report all
                                        names that respond to stat

> 	STATX_INFO_NONSYSTEM_OWNERSHIP	File has non-system ownership details

This probably is a well defined meaning that I just don't have the
context to understand.  For me, more words would help here.

I don't object to any of these flag.  I just want to be sure that I
understand them.
I am generally in favour this functionality going in promptly.

Thanks,
NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)