ntfs-3g
ntfs-3g copied to clipboard
tuxera
Mounting in read-only mode allows access times to be changed
Problem description: When mounting an NTFS filesystem in read-only (ro) mode using the mount command, accessing a file still updates its access time.
Why is this a problem? Other filesystems (such as ext4) do not modify file access times when mounted read-only.
I feel it worth mentioning that when using "ntfs-3g -o ro /dev/device mount-point" to mount NTFS,file access times are not updated. File access times are only updated when mounting the NTFS volume using "mount -o ro /dev/device mount-point".
Steps to reproduce:
dd if=/dev/zero of=ntfs.img count=102400 mkfs.ntfs --force ntfs.img mkdir disk mount.ntfs-3g ntfs.img disk cp somefile.txt disk/ umount disk
mount -o ro ntfs.img disk stat disk/somefile.txt (shows access time) sleep 60 cat disk/somefile.txt stat disk/somefile.txt (shows updated access time)
Note: When mounting ntfs.img using "ntfs-3g -o ro ntfs.img disk" the file access times are not changed.
When this same test is doen with ext4, file access times do not change.
Test system: Debian 11, running kernel 5.10
Running mount.ntfs-3g --version gives the following information: "ntfs-3g 2017.3.23AR.3 integrated FUSE 28"
Additional discussion on this issue is happening in this Reddit thread: https://old.reddit.com/r/linux/comments/vhpdp3/mount_o_ro_does_not_writeprotect_last_access/
I haven't analyzed this issue very thoroughly but in general the 'remount' functionality in FUSE AFAIK has no callback in libfuse, but is purely implemented in the kernel with no real calls to libfuse.
This means that the FUSE daemon doesn't know that it has been remounted as read-only, and proceeds to update access times as if it was a read-write mount.
I will check if there's any new callback to support remount functionality in libfuse. If not, then the FUSE 'remount' feature is inherently flawed.
I don't think this is just a remount issue. This problem seems to crop up even when the volume is umounted and then mounted again later in read-only mode.
Problem description: When mounting an NTFS filesystem in read-only (ro) mode using the mount command, accessing a file still updates its access time.
Strange. When mounting read-only, there are three barriers preventing from actually write to device : the device is opened read-only, a read-only flag prevents from writing to the device and another read-only flags prevents from writing to the volume.
I suspect an update taking place in the cache, I would be suprised if it actually makes it to the device. Several cache issues are known with fuse which apparently cannot be solved. Anyway this has to be checked.
I rewrote your tests as :
dd if=/dev/zero of=ntfs.img count=102400
mkfs.ntfs --force ntfs.img
if ! [ -d disk ]
then
mkdir disk
fi
echo step 1
mount.ntfs-3g ntfs.img disk
cp somefile.txt disk/
sleep 5
umount disk
sleep 60
echo step 2
mount -o ro ntfs.img disk
stat disk/somefile.txt
#(shows access time)
sleep 5
cat disk/somefile.txt
stat disk/somefile.txt
#(shows updated access time)
sleep 5
umount disk
echo step 3
mount -o ro ntfs.img disk
stat disk/somefile.txt
sleep 5
umount disk
Note the added "sleep" around umounts, often useful because they are asynchronous, otherwise we end up with multiple mounts.
This is what I get :
step 1
step 2
File: disk/somefile.txt
Size: 7 Blocks: 1 IO Block: 4096 regular file
Device: 700h/1792d Inode: 64 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-06-22 16:22:05.340221600 +0200
Modify: 2022-06-22 16:22:05.340520500 +0200
Change: 2022-06-22 16:22:05.340520500 +0200
Birth: -
azerty
File: disk/somefile.txt
Size: 7 Blocks: 1 IO Block: 4096 regular file
Device: 700h/1792d Inode: 64 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-06-22 16:22:05.340221600 +0200
Modify: 2022-06-22 16:22:05.340520500 +0200
Change: 2022-06-22 16:22:05.340520500 +0200
Birth: -
step 3
File: disk/somefile.txt
Size: 7 Blocks: 1 IO Block: 4096 regular file
Device: 700h/1792d Inode: 64 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-06-22 16:22:05.340221600 +0200
Modify: 2022-06-22 16:22:05.340520500 +0200
Change: 2022-06-22 16:22:05.340520500 +0200
Birth: -
This is on a recent version of ntfs-3g, but I do not remember of a significant change in mountings since 2017.3.23AR.3
What do you have in your syslog ? you may have some specific configuration. I get three times what follows :
Version 2021.8.22 integrated FUSE 28
Mounted /dev/loop0 (Read-Only, label "", NTFS 3.1)
Cmdline options: ro
Mount options: ro,allow_other,nonempty,relatime,fsname=/dev/loop0,blkdev,blksize=4096
Ownership and permissions disabled, configuration type 7
red-ntfs-ntfslow-ntfs\x2d3g-disk.mount: Succeeded.
Unmounting /dev/loop0 ()
@unsound : your comment apparently belongs to issue #42
Ah, I missed that one. It seems that this issue should be merged with #42 as it's essentially the same problem.
I do no think #42 and #43 are related. #42 is related to an explicit remount option with a single effective mounting. #43 may be caused by an asynchronous umount not taking place before the next mount, which means the device remains mounted as rw. I need the syslog to be sure.
I tried doing the mount a few times, both in rw mode and ro mode. It looks like a syslog entry only gets added when I do the first mount (or an umount, new mount). It doesn't add a new syslog entry if I remount.
Anyway, here are my two most recent syslog entries, the first from when I mounted the NTFS volume in read-write mode and the second where I did a fresh umount/mount in read-only mode.
ntfs-3g[243205]: Version 2017.3.23AR.3 integrated FUSE 28
ntfs-3g[243205]: Mounted /dev/loop0 (Read-Write, label "", NTFS 3.1)
ntfs-3g[243205]: Cmdline options: rw
ntfs-3g[243205]: Mount options: allow_other,nonempty,relatime,rw,fsname=/dev/loop0,blkdev,blksize=4096
ntfs-3g[243279]:Version 2017.3.23AR.3 integrated FUSE 28
ntfs-3g[243279]: Mounted /dev/loop0 (Read-Only, label "", NTFS 3.1)
ntfs-3g[243279]: Cmdline options: ro
ntfs-3g[243279]: Mount options: ro,allow_other,nonempty,relatime,fsname=/dev/loop0,blkdev,blksize=4096
I tried doing the mount a few times, both in rw mode and ro mode. It looks like a syslog entry only gets added when I do the first mount (or an umount, new mount).
This is expected (first mount, or after effective umount). Please show both a modified access time condition and the corresponding syslog. If the umount is late, the second mount is rejected and not seen in the syslog.
It doesn't add a new syslog entry if I remount.
This is also expected, but there is no remount in your original sequence, only successive mounts.
Some food for thought https://dfir.ru/2018/07/25/a-live-forensic-distribution-writing-to-a-suspect-drive/
