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

@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/