On Fri, Feb 15, 2019 at 09:06:26AM +1100, Dave Chinner wrote:

On Thu, Feb 14, 2019 at 02:00:07AM -0800, Omar Sandoval wrote:

quoted

From: Omar Sandoval <redacted>

Hi,

Since statx was added in 4.11, userspace has had an interface for
reading btime (file creation time), but no way to set it. This RFC patch
series adds support for changing btime with utimensat(). Patch 1 adds
the VFS infrastructure, patch 2 adds the support to utimensat() with a
new flag, and the rest of the patches add filesystem support; I excluded
CIFS for now because I don't have a CIFS setup to test it on.

Updating btime is useful for at least a couple of use cases:

- Backup/restore programs (my motivation for this feature is btrfs send)
- File servers which interoperate with operating systems that allow
  updating file creation time, including Mac OS [1] and Windows [2]

So you're adding an interface that allows users to change the create
time of files without needing any privileges?

I think it'd be reasonable to make this a privileged operation. I didn't
for this initial submission for a couple of reasons:

1. The precedent on Mac OS and Windows is that this isn't a privileged
   operation.
2. I knew there would be different opinions on this either way I went.

Inode create time is forensic metadata in XFS  - information we use
for sequence of event and inode lifetime analysis during examination
of broken filesystem images and systems that have been broken into.
Just because it's exposed to userspace via statx(), it doesn't mean
that it is information that users should be allowed to change. i.e.
allowing users to be able to change the create time on files makes
it completely useless for the purpose it was added to XFS for...

And allowing root to change the create time doesn't really help,
because once you've broken into a system, this makes it really easy
to cover tracks

If the threat model is that the attacker has root, then they can
overwrite the timestamp on disk anyways, no?

(e.g. we can't find files that were created and
unlinked during the break in window anymore) and lay false
trails....

Fair point, although there's still ctime during the break-in window,
which I assume you'd be looking for anyways since files modified during
the break-in window are also of interest.

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.

Thanks!