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: <20250311003119.GM2023217@ZenIV>
Date: Tue, 11 Mar 2025 00:31:19 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: David Laight <david.laight.linux@...il.com>
Cc: Theodore Ts'o <tytso@....edu>, "Artem S. Tashkinov" <aros@....com>,
	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 10:12:43PM +0000, David Laight wrote:
> On Mon, 10 Mar 2025 09:58:28 -0400
> "Theodore Ts'o" <tytso@....edu> 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.
> > 
> 
> I'm sure that hadn't used to be the case.

You are incorrect.

> But as some point the 'ctime' changed from something that was usually
> the file create time (for some definition of create) to a pretty useless
> time that is almost a waste of disk space.

Which point would that be, considering that v6 inodes have only two timestamps
(atime and mtime), while in v7 e.g. chmod() definitely does update ctime?

sys/sys4.c:chmod():
        ip->i_flag |= ICHG;
	...
	iput(ip);
sys/iget.c:iput():
        if(ip->i_count == 1) {
		...
		iupdat(ip, &time, &time);
sys/iget.c:iupdat():
                if(ip->i_flag&ICHG)
			dp->di_ctime = time;

And filesys(5) has this:
.I Di_ctime
records the time of last modification
to the inode or to the file, and is used
to determine whether it should be dumped.

... which ought to answer the question about the intended use of that thing.
Hopefully useful mnemonics for your next attempt at UNIX101:
	A: Accessed
	M: contents Modified
	C: Changed in any way, including metadata