linux-kernel - Re: A syscall for changing birth time

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250310153744.GD8837@mit.edu>
Date: Mon, 10 Mar 2025 11:37:44 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: "Artem S. Tashkinov" <aros@....com>
Cc: linux-ext4@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: A syscall for changing birth time

On Mon, Mar 10, 2025 at 02:11:13PM +0000, Artem S. Tashkinov wrote:
> 
> I'm not going to argue with your reasoning but being able to set btime
> could be beneficial for backup and restore purposes/utilities.

I think the fundmental question is should we change the current
defined semantics of btime, versus adding some new "crtime" field for
those people who care about Windows compatibility.

Granted, it's only been relatively recently that userspace could even
*access* btime for a file in the a mounted file system via the
statx(2) system call.  So there might not be that many users of btime
today, so changing the semantics might not break userspace (much).

Again, the choices are:

* Change semantics of "birth time" for everyone as of some new kernel version

* Make the semantics of "birth time" be subject to chagge via a mount option

* Add the ability to optionally store a new "creation time" which as
  Windows semantics in addition to btime.  This could either be via an
  xattr, or by adding a new on-disk inode field for some file systems
  that care about Windows compatibility.

> Secondly, I really like having separate modification and creation times
> for all my files.

Personally, I don't find it all that useful, since "creation time" is
really (with apologies to Lewis Carroll):

   “When I use a timestamp,’ Humpty Dumpty said in rather a scornful tone, ‘it
    means just what I choose it to mean — neither more nor less.’

    ’The question is,’ said Alice, ‘whether you can make timestamps mean so
    many different things.’

    ’The question is,’ said Humpty Dumpty, ‘which is to be master — that’s all.”

.... combined with the fact that most file systems don't support
creation time today.

Hence I find it more useful to find some other way to do version
stamping --- and something more reliable, like a SHA1 hash like git
uses.  Or as a nother example, using an external database, such as a
rpm or dpkg installed package database, with a crypto hash to verify
whether the file has actually changed, no matter what the package
manager thinks.

But that's just my personal opinion.  I am sure that other people
might find "creation time" to be useful.

> Finally, as for POSIX not offering this feature - doesn't Linux already
> have a lot of syscalls that are not found in POSIX?

What I was trying to point out that there is precedent in POSIX not
allowing certain timestamps to be changed, because that would violate
the semantics of ctime --- and the same would apply for btime's
current semantics.

Can we forcibly change btime's semantics?  Perhaps.  But let's do so
consciously, and not blindly follow Windows' way of doing things.

Cheers,

	     	     	     	    	     	 - Ted