linux-kernel - Re: [RFC][PATCH 0/4] Enhanced file stat system call

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, 17 Nov 2016 14:39:04 +0000
From:   One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:     David Howells <dhowells@...hat.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 0/4] Enhanced file stat system call

>  (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of
>      interest, and allow a network fs to approximate anything not of
>      interest, without going to the server.
> 
>  (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flush
>      buffers and go to the server, even if it thinks its cached attributes
>      are up to date.

That seems an odd way to do it. Wouldn't it be cleaner and more flexible
to give a timestamp of the oldest time you consider acceptable (and
obviously passing 0 indicates whatever you have)

>  (4) Allow the filesystem to indicate what it can/cannot provide: A
>      filesystem can now say it doesn't support a standard stat feature if
>      that isn't available.
> 
>  (5) Make the fields a consistent size on all arches, and make them large.
> 
>  (6) Can be extended by using more request flags and using up the padding
>      space in the statx struct.
> 
> Note that no lstat() equivalent is required as that can be implemented
> through statx() with atflag == 0.  There is also no fstat() equivalent as
> that can be implemented through statx() with filename == NULL and the
> relevant fd passed as dfd.

and dfd + a name gives you fstatat() ? The cover note could be clearer on
this.

Should the fields really be split the way they are for times rather than
a struct for each one so you can write code generically to handle one of
those rather than having to have a 4 way switch statement all the time.

Another attribute that would be nice (but migt need some trivial device
layer tweaking) would be STATX_ATTR_VOLATILE for filesystems that will
probably evaporate on a reboot. That's useful information for tools like
installers and also for sanity checking things like backup paths.

Remote needs to have clear semantics: is ext4fs over nbd 'remote' for
example ?

Alan