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: <69d8b100-f65d-470f-a957-2819795e82a4@gmx.com>
Date: Mon, 10 Mar 2025 14:11:13 +0000
From: "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 3/10/25 1:58 PM, Theodore Ts'o wrote:
> On Mon, Mar 10, 2025 at 07:26:00AM +0000, Artem S. Tashkinov wrote:
>>
>> Why is it that the Linux kernel supports reading btime, but there's no
>> syscall to change it? At least for ext4 there's the debugfs utility, but
>> for other filesystems there's just nothing. And even debugfs is not a
>> solution, since it requires root privileges and an unmounted/mounted RO
>> filesystem.
>
> POSIX and Single Unix Specification also doesn't provide a way to
> allow userspace to set ctime (inode change time).  That's because the
> definition of "change time" is defined to include the time to change
> anything about the inode metadata --- including the inode timestamps.
>
> Simply, the definition of "birth time" is about the time that the
> inode was "birthed", and that's not something that you can change.
> The problem is that DOS has a concept of "creation time", which seems
> to mean "the time that the abstract concept of the file was created".
> So if a file was created somewhere in a build farm in Redmond,
> Washington, that's the time that the file should have, according to
> Microsoft.  So Windows allows the "creation time" to be set to any
> arbitrary file, since installers need to be able to set the "abstract
> creation time".
>
> You can debate whether "birth time" (which can't be set) or a
> "abstract creation time" (which can set to any arbitrary value), is
> "better" but that's why Linux doesn't support a way to set the "birth
> time".
>
> Whether you think we should bow to what Microsoft dictates probably
> depends on how much you believe Windows is a legacy operating system
> or not.  :-)  Personally, it's not something I really care about, and
> if someone really wants to add a Windows-compatible "Creation Time",
> my suggestion would be to define an extended attribute where this
> could be stored.
>
> We *could* allocate space in the on-disk inode to store this
> timestamp, but since I would estimate 99.9% of deployed Linux systems
> don't care about Windows compatibility, it's not a good use of
> resources.  We could also add a mount option which changes the
> semantics of birth time, but that adds extra complexity, and again, I
> would estimate that 99.9% of Linux systems (where I include all of the
> Linux deployments in Cloud VM's) don't care about Windows
> compatibility in this way.
>
> Cheers,
>
> 						- Ted

Hello,

I'm not going to argue with your reasoning but being able to set btime
could be beneficial for backup and restore purposes/utilities.

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

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

So, it's not just about Windows compatibility. It's just very useful.

Regards,
Artem