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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sat, 23 Feb 2019 10:32:37 -0800
From:   Andreas Dilger <adilger@...ger.ca>
To:     Omar Sandoval <osandov@...ndov.com>
Cc:     Dave Chinner <david@...morbit.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>, kernel-team@...com,
        Linux API <linux-api@...r.kernel.org>,
        linux-btrfs <linux-btrfs@...r.kernel.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        linux-f2fs-devel@...ts.sourceforge.net,
        linux-xfs <linux-xfs@...r.kernel.org>,
        Theodore Ts'o <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        Steve French <sfrench@...ba.org>
Subject: Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat()


> On Feb 22, 2019, at 11:00 AM, Omar Sandoval <osandov@...ndov.com> 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






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)