[FUSE API] Cannot make entries in the file system show as read-only

[mhx]

Bug Report

I didn't add this to #84 as it think it's a distinct problem.

I don't seem to be able to make any entries in a FUSE file system over WinFsp appear as read-only. It's absolutely possible that I'm just doing it wrong, but I have a hard time figuring out what's going on.

I'm going to compare Linux and Windows/WinFsp again.

How to Reproduce

First of all, I'm checking whether stat correctly reports read-onlyness:

C:\Users\mhx\git\dwarfs\build-vcpkg>stat readonly
  File: readonly
  Size: 0               Blocks: 0          IO Block: 65536  regular empty file
Device: e6264b9dh/3861269405d   Inode: 6192449488108405  Links: 1
Access: (0444/-r--r--r--)  Uid: (197608/     mhx)   Gid: (197121/    None)
Access: 2023-07-01 13:47:16.561593600 +0200
Modify: 2023-07-01 13:46:58.712226600 +0200
Change: 2023-07-01 13:47:19.578963800 +0200
 Birth: 2023-07-01 13:46:58.709573400 +0200

So that seems to work. Now, while my file system is inherently read-only, permissions of the files are fully preserved and they will show up as writable. This ensures you can do things like rsync from the file system and get the original permissions back. However, I can explicitly pass a readonly option to the FUSE driver, which will cause all write permission bits to be stripped from the file status retrieved by getattr.

Now, here's what happens on Linux:

mhx@air build-clang [mhx/windows-build] $ ./dwarfs boost.dwarfs mnt
mhx@air build-clang [mhx/windows-build] $ stat mnt/INSTALL 
  File: mnt/INSTALL
  Size: 291             Blocks: 1          IO Block: 512    regular file
Device: 0,53    Inode: 63570       Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-06-25 20:44:15.000000000 +0200
Modify: 2023-06-25 20:44:15.000000000 +0200
Change: 2023-06-25 20:44:15.000000000 +0200
 Birth: -
mhx@air build-clang [mhx/windows-build] $ ./dwarfs boost.dwarfs mnt -oreadonly
mhx@air build-clang [mhx/windows-build] $ stat mnt/INSTALL 
  File: mnt/INSTALL
  Size: 291             Blocks: 1          IO Block: 512    regular file
Device: 0,53    Inode: 63570       Links: 1
Access: (0555/-r-xr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-06-25 20:44:15.000000000 +0200
Modify: 2023-06-25 20:44:15.000000000 +0200
Change: 2023-06-25 20:44:15.000000000 +0200
 Birth: -

On Windows, no matter what is being returned by getattr, the status looks like this:

C:\Users\mhx\git\dwarfs\build-vcpkg>stat mnt\INSTALL
  File: mnt\INSTALL
  Size: 291             Blocks: 4          IO Block: 65536  regular file
Device: 7485c818h/1954924568d   Inode: 63569       Links: 1
Access: (0644/-rw-r--r--)  Uid: (197608/     mhx)   Gid: (197121/    None)
Access: 2023-06-25 20:44:15.000000000 +0200
Modify: 2023-06-25 20:44:15.000000000 +0200
Change: 2023-06-25 20:44:15.000000000 +0200
 Birth: -

Also, no matter what I pass to -oumask, the outcome doesn't change (though I don't really know if passing this option actually works, see #516).

Behaviors

I'd expect files without any write permissions to show up as read-only.

Environment

• OS version and build: 10.0.22621
• WinFsp version and build: 2.0.23075

[billziss-gh]

What are you setting the umask as? Off the top of my head -o umask=222 should work to remove read permissions.

I recommend something like -o uid=-1,umask=222 to make files and directories owned by the user that launches the file system without read permissions.

[mhx]

Preferably I wouldn't want to set the umask at all, but rather see the permission bits reported by getattr() propagated through WinFsp.

In any case, setting e.g. umask=777 does work to the extent that I cannot access the data any longer. So that's good. However, it still doesn't affect what stat is seeing, which makes me doubt the usefulness of that tool on Windows.

[billziss-gh]

You do not need to use the umask option; it is only a crude tool for when there is no proper getattr implementation or when one needs to override the getattr implementation.

I am not sure what stat tool you are using. WinFsp-FUSE emulates UNIX permissions using the same technique as Cygwin, so using Cygwin's stat should work. But I recommend using WinFsp's own fsptool, which reports both the Windows (real) permission (in SDDL format) and the (emulated) UNIX permission. From Powershell use: . "C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe" perm .\path\to\file (the \ backslash is important otherwise the perm argument will not be interpretted as a path).

---

In a nutshell, WinFsp does not currently properly support read-only file systems. You can advertise a file system as read-only, but you may have to return "access denied" (EPERM or EACCES -- I would not recommend EROFS) from some file system modifying operations. You can also return the correct file mode from getattr and WinFsp and Windows will honor it (e.g. they will not normally allow a file to be opened for writing).

Finally you may have to add some special handling to your file system to recognize the -o readonly flag and ensure that your getattr implementation omits the write permission from the stat information that it returns.

[mhx]

Sorry, I must have completely missed your reply.

Finally you may have to add some special handling to your file system to recognize the -o readonly flag and ensure that your getattr implementation omits the write permission from the stat information that it returns.

This is exactly what my file system is doing when the -o readonly option gets passed in. There are no write permission bits set in st_mode, yet the files presented through WinFsp show up as writable. Hence why I thought this might be related to the umask option.

[mhx]

Here's the output of fsptool:

PS C:\Users\mhx\git\dwarfs\build-vcpkg> . 'C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe' perm .\mnt\subdir\test.txt
O:S-1-5-0G:S-1-5-0D:P(A;;0x1f01b9;;;S-1-5-0)(A;;0x1200a9;;;S-1-5-0)(A;;0x1200a9;;;WD) (perm=0:0:0555)

I assume the (perm=0:0:0555) is what's reported from my file system. The file in question, however, is not reported as read-only to the OS.