winfsp using programs exit without a reason if volname option has more than 32 characters

[mhogomchungu]

How to Reproduce

Use sshfs-win to connect to a remote server and use -o volname option with less than 32 characters and observer it working as expected

C:\Users\Ink> "C:\Program Files\SSHFS-Win\\bin\sshfs.exe" -f "ink@192.168.43.100:/home/ink/Music" "Y:"  -o volname="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
ssh: connect to host 192.168.43.100 port 22: No route to host
read: Connection reset by peer

C:\Users\Ink>

Run the same command again and add more characters to volname option and observe sshfs exiting without printing anything

C:\Users\Ink> "C:\Program Files\SSHFS-Win\\bin\sshfs.exe" -f "ink@192.168.43.100:/home/ink/Music" "Y:"  -o volname="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

C:\Users\Ink>

The same behavior is observed with securefs

C:\Users\Ink\bin>securefs mount C:\Users\Ink\Desktop\securefs E: -o volname=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Enter password:

C:\Users\Ink\bin>

• OS version and build: windows 10, version 1903,build number 18362.356
• WinFsp version and build: 2020

[billziss-gh]

Thanks for the report. Likely a buffer overflow bug in the handling of the volname option.

[billziss-gh]

@mhogomchungu I looked into this and the behavior appears to be "by design" (please note that this does not make it a "good" behavior and we should probably change it).

The volname option is handled at this location: fsp_fuse_core_opt_proc. The volname option is transformed from UTF-8/multibyte format to the internal UTF-16/widechar format using MultiByteToWideChar. This is necessary because Windows and WinFsp internally deal with WCHAR characters, whereas FUSE is a char API.

Now a volume label can be up to 32 characters long. So when passed a volname longer than 32 characters, MultiByteToWideChar will fail, which will result in fsp_fuse_core_opt_proc to fail and consequently the FUSE options parsing to fail. These failures are "graceful" in the sense that the running process cleans up after itself and exits without crashing.

Unfortunately no error messages are printed, which is very confusing from a user perspective. It can be easily argued that this behavior is a poor design choice and that error messages should be added to explain the situation.

I note that there are other places were the same problem can happen. For example, the same problem would happen if the supplied file system name was too long: https://github.com/billziss-gh/winfsp/blob/v1.7/src/dll/fuse/fuse.c#L357-L371

[mhogomchungu]

A possible solution is to make sure the volname variable does not exceed 32 characters by truncating excess ones.

If a user for example gives a value that is too long, winfsp accepts it but set the variable that is equal to 29 characters from the user followed by 3 dots to indicate truncation.

An example of a truncated string looks like: zzzzzzzzzzzzzzzzzzzzzzzzzzzz...

[billziss-gh]

I have added commit c803ef2 which should address this issue.