On Tue, Feb 19, 2019 at 09:18:20AM +1100, Dave Chinner wrote:

On Sat, Feb 16, 2019 at 06:57:45PM -0700, Andreas Dilger wrote:

quoted

While it may be a bit of a stretch to call this "forensic evidence", making

We do forensic analysis of corrupt filesystems looking for evidence
of what went wrong, not just looking for evidence of what happened
on systems that have been broken into.

quoted

it hard to change from except via total root compromise by a skilled hacker
is very useful.

*nod*.

quoted

If this were to go in (which I'm not in favour of), then there would need to
be a CONFIG and/or runtime knob to turn it off (or better to only turn it on),
similar to how FIPS and other security options can only go in one direction.

The problem here is that "inode birth time" is being conflated with
"user document creation time". These two things are very different.

i.e. One is filesystem internal information and is not related to
when the original copy of the data in the file was created, the
other is user specified metadata that is related to the file data
contents and needs to travel with the data, not the filesystem.

IMO, trying to make one on-disk field hold two different types of
information defeats one or the other purpose, and nobody knows which
one the field stores for any given file.

I'd suggest that "authored date" should be a generic system xattr so
most filesystems support it, not just those that have a birth time
field on disk. Sure, modify it through utimesat() and expose it
through statx() (as authored time, not birth time), but store it a
system xattr rather than an internal filesystem metadata field that
requires was never intended to be user modifiable.

It seems that this is the general consensus, so I'll look into
implementing this functionality as an xattr.