> On Feb 22, 2019, at 11:00 AM, Omar Sandoval <osandov@xxxxxxxxxxx> wrote: > > 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: >>> While it may be a bit of a stretch to call this "forensic evidence", >> >> 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. >> >>> making it hard to change from except via total root compromise by a >>> skilled hacker is very useful. >> >> *nod*. >> >>> 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. I would recommend to look at how Samba is storing these attributes today, and do the same thing, maybe add support into GNU coreutils to handle this transparently. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
