From: Omar Sandoval <osandov@osandov.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-fsdevel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
kernel-team@fb.com, linux-api@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-xfs@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
Steve French <sfrench@samba.org>
Subject: Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat()
Date: Thu, 14 Feb 2019 22:59:47 -0800 [thread overview]
Message-ID: <20190215065947.GG9819@vader> (raw)
In-Reply-To: <20190215001657.GY14116@dastard>
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:
> > 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:
> > > > From: Omar Sandoval <osandov@fb.com>
> > > >
> > > > 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.
>
> Don't really care about them. Interop file servers that support these
> operations on other OSs will need to be storing this info in xattrs
> because they have to work on filesystems that don't support btime.
>
> > 2. I knew there would be different opinions on this either way I went.
>
> Yup.
>
> > > 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?
>
> Modifying the block devicee under an active filesystem is fraught
> with danger, and there's no guarantee it will work if the metadata
> being modified is still active in memory. Corrupting the filesystem
> is a sure way to get noticed....
>
> > > (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,
>
> Unless you're smart enough to know how to trigger S_NOCMTIME or
> FMODE_NOCMTIME....
>
> > which I assume you'd be looking for anyways since files modified during
> > the break-in window are also of interest.
>
> ... and then that also can't be guaranteed. :/
>
> > 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.
next prev parent reply other threads:[~2019-02-15 7:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 10:00 [RFC PATCH 0/6] Allow setting file birth time with utimensat() Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 1/6] fs: add btime to struct iattr Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 2/6] fs: add AT_UTIME_BTIME for utimensat() Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 3/6] Btrfs: add support for setting btime Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 4/6] ext4: " Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 5/6] f2fs: " Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 6/6] xfs: " Omar Sandoval
2019-02-14 10:00 ` [PATCH] generic: add a test for AT_UTIME_BTIME Omar Sandoval
2019-02-14 10:00 ` [PATCH] utimensat2: document AT_UTIME_BTIME Omar Sandoval
2019-02-14 10:00 ` [PATCH] xfs_io: add AT_UTIME_BTIME support Omar Sandoval
2019-02-14 22:06 ` [RFC PATCH 0/6] Allow setting file birth time with utimensat() Dave Chinner
2019-02-14 23:14 ` Omar Sandoval
2019-02-15 0:16 ` Dave Chinner
2019-02-15 6:59 ` Omar Sandoval [this message]
2019-02-15 13:57 ` David Disseldorp
2019-02-17 1:57 ` Andreas Dilger
2019-02-18 22:18 ` Dave Chinner
2019-02-22 19:00 ` Omar Sandoval
2019-02-23 18:32 ` Andreas Dilger
2019-02-17 16:35 ` Boaz Harrosh
2019-02-17 17:54 ` Adam Borowski
2019-02-17 20:40 ` Andy Lutomirski
2019-02-19 4:04 ` Matthew Wilcox
2019-02-19 4:28 ` Dave Chinner
2019-02-20 7:47 ` Andreas Dilger
2019-02-15 1:57 ` Hans van Kranenburg
2019-02-15 5:39 ` Omar Sandoval
2019-02-15 18:25 ` Hans van Kranenburg
2019-02-22 15:02 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190215065947.GG9819@vader \
--to=osandov@osandov.com \
--cc=david@fromorbit.com \
--cc=jaegeuk@kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sfrench@samba.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).