Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Feb 14, 2019, at 11:59 PM, Omar Sandoval <osandov@xxxxxxxxxxx> wrote:
> 
> On Fri, Feb 15, 2019 at 11:16:57AM +1100, Dave Chinner wrote:
>> On Thu, Feb 14, 2019 at 03:14:29PM -0800, Omar Sandoval wrote:
>>> I see a few options, none of which are particularly nice:
>>> 
>>> 1. Filesystems like XFS could choose not to support setting btime even
>>>   if they support reading it.
>>> 2. XFS could add a second, writeable btime which is used for
>>>   statx/utimes when available (it would fit in di_pad2...).
>>> 3. We could add a btime_writable sysctl/mount option/mkfs option.
>> 
>> 4. create time remains a read-only field, and btrfs grows its own
>> special interface to twiddle it in btrfs-recv if it really is
>> necessary.
> 
> I'm curious to hear what the ext4/f2fs/CIFS developers think. If no one
> else wants btime to be mutable, then I might as well make it
> Btrfs-specific. That is, assuming we reach consensus on the Btrfs side
> that btrfs receive should set btime.
> 
>> I'm still not convinced that even backup/restore should be doing this,
>> because there's so much other metadata that is unique even on
>> restored files that it doesn't really make any sense to me to lie
>> about it being created in the past....
> 
> I suppose it depends on how you interpret btime: if it's strictly
> filesystem metadata, then it makes sense that it should be immutable; if
> it's metadata for the user's own purposes, then we should allow setting
> it.

My personal preference is that crtime/btime be read-only information that
tells when the file itself was created in this filesystem, not some added
metadata that is managed by userspace.  There have been many times when
I've needed to know when a file was _actually_ created in the filesystem,
not what mtime/ctime report.

While it may be a bit of a stretch to call this "forensic evidence", making
it hard to change from except via total root compromise by a skilled hacker
is very useful.

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.

Cheers, Andreas





Attachment: signature.asc
Description: Message signed with OpenPGP


[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux