Re: [RFC PATCH v3 3/5] ntfs3: make crtime user-settable using ptime

["Pali Rohár" <pali@kernel.org>]

On Sunday 01 November 2026 02:55:49 koraynilay wrote:
> @@ -154,6 +158,11 @@ int ntfs_fileattr_set(const struct mnt_idmap *idmap, struct dentry *dentry,
>  	if (flags & FS_APPEND_FL)
>  		new_fl |= S_APPEND;
>  
> +	if (fa->fsx_xflags & FS_XFLAG_PTIME) {
> +		ni->i_crtime.tv_sec = fa->fsx_ptime.tv_sec;
> +		ni->i_crtime.tv_nsec = fa->fsx_ptime.tv_nsec;
> +	}
> +
>  	inode_set_flags(inode, new_fl, S_IMMUTABLE | S_APPEND);
>  
>  	/* Save nodump flag to return in ntfs_getattr. */
> @@ -275,8 +284,9 @@ int ntfs_getattr(const struct mnt_idmap *idmap, const struct path *path,
>  	if (unlikely(is_bad_ni(ni)))
>  		return -EINVAL;
>  
> -	stat->result_mask |= STATX_BTIME;
> +	stat->result_mask |= (STATX_BTIME | STATX_PTIME);
>  	stat->btime = ni->i_crtime;
> +	stat->ptime = ni->i_crtime;

For me this patch looks dangerous. Somehow I would expect that the
"btime" will never change for existing inode.

But because the ptime is mapped to i_crtime and ptime is settable from
userspace, with this patch it is directly possible to change btime.



I was thinking more about it... Is not this just misunderstanding of how
the security model around the times is working on different systems?
Because on NTFS there is stored just one field which says when the file
was created. There are not two fields like "time set by user and time
set by system".

Windows security model allows anybody with WRITE_ATTRIBUTES access to
change that create time. Linux security model does not allow to change it.

NTFS in this view is just a filesystem like any other (ext4, btrfs, ...).
In my opinion if the ext4 or btrfs filesystem is correctly implemented
on Windows systems, then Windows security model should handle it in the
same way like for NTFS or exFAT. So if something grants WRITE_ATTRIBUTES
access, then Windows should allow to change also btime on ext4 or btrfs.



On the other hand, I understand the use case to have two creation times.
One time which would never be changed and could be used for any kind of
atomic / synchronization by userspace application logic (this btime).
And another time for human which can be changed at any time to any value
which user wants (this ptime).

In any case, I would suggest that filesystem driver would not report to
userspace unsupported values and would not try to invent other values
and lying about them.