Dev1 Galaxy Forum / Automounting USB Drives (NTFS, exFAT) with dmask=022,fmask=133

Re: Automounting USB Drives (NTFS, exFAT) with dmask=022,fmask=133

dummy@example.com (igorzwx) — Thu, 26 Jun 2025 21:40:25 +0000

On Ubuntu, the NTFS driver (read and write) was installed and enabled by default since 2007.
It worked without problems and "compatibility issues".
It seems that this particular security problem occurred about ten years ago, for example:
_https://unix.stackexchange.com/questions/296967/how-to-recursively-remove-execute-permissions-from-files-without-touching-folder
_https://unix.stackexchange.com/q/296967
Nothing was done to fix it.
You may not believe, but computer science students (and their professors, perhaps), usually do not notice that this problem exists. They simply install Ubuntu and use it for their projects.
It might be obvious that this strange phenomenon correlates with pulseaudio and systemd.
It is very probable that it is a symptom of dementia caused by pulseaudio and enhanced by pipewire.

EDIT:
Because of dementia, it might be difficult to understand that what kind of security problem it is.
It is a backdoor in Devuan.

It seems that Stuxnet is already forgotten (because of dementia).

It is typically introduced to the target environment via an infected USB flash drive, thus crossing any air gap. The worm then propagates across the network, scanning for Siemens Step7 software on computers controlling a PLC.
_https://en.wikipedia.org/wiki/Stuxnet

Uh-oh. How just inserting a USB drive can pwn a Linux box
_https://www.bitdefender.com/en-us/blog/hotforsecurity/uh-oh-how-just-inserting-a-usb-drive-can-pwn-a-linux-box

CVE-2025-37986 is a vulnerability discovered in the Linux kernel's USB Type-C device pointer handling system, disclosed on May 20, 2025.
_https://www.wiz.io/vulnerability-database/cve/cve-2025-37986

Linux USB Subsystem Vulnerabilities
Fourteen vulnerabilities have been found to be affecting the USB subsystem on Linux. The vulnerabilities affect all Linux devices with USB ports. However, physical access is required to initiate them.
Threat ID:
CC-1777
Category:
Exploit
Threat Severity:
Low
Threat Vector:
Published:
14 November 2017 12:00 AM
_https://digital.nhs.uk/cyber-alerts/2017/cc-1777

Researchers found 26 new vulnerabilities in the USB drivers used in Windows, Linux, macOS and other systems.
_https://www.hugdiy.com/blog/you-wouldnt-know-until-you-test-it-how-to-restore-all-these-usb-vulnerabilities/

Re: Automounting USB Drives (NTFS, exFAT) with dmask=022,fmask=133

dummy@example.com (Devarch) — Thu, 26 Jun 2025 20:45:49 +0000

Nobody complains, and nobody is trying to fix the problem.
This seems to be a symptom of dementia caused by pulseaudio and pipewire.

It is important to note that consideration should be given when using exFAT or NTFS file systems on Linux systems. These file systems (M$) are not natively supported by Linux, and their usage carries risks due to potential compatibility issues.

In other words, micro$ FS should remain on your desk next to the window — like a broken vase. Though I find exFAT extremely useful for file exchange.

Re: Automounting USB Drives (NTFS, exFAT) with dmask=022,fmask=133

dummy@example.com (igorzwx) — Thu, 26 Jun 2025 14:28:06 +0000

The latest version of Linux Mint (22.1) has the same security problem.
USB Drives (NTFS, exFAT) are automatically mounted with all files executable.
Nobody complains, and nobody is trying to fix the problem.

This seems to be a symptom of dementia caused by pulseaudio and pipewire.
It may also explain a strange phenomenon of Neo-Luddism and AI hate
_https://en.wikipedia.org/wiki/Neo-Luddism
_https://en.wikipedia.org/wiki/Luddite

Perhaps, it is too late to do something about Devuan Wiki.

Re: Automounting USB Drives (NTFS, exFAT) with dmask=022,fmask=133

dummy@example.com (igorzwx) — Tue, 10 Sep 2024 14:34:24 +0000

Hope it works for you.

PedroReina wrote:

After 20 years, at last I know how to fix this annoying behaviour.

I thought that it is a special feature of Devuan.
If it is "annoying behaviour" for you, it does not mean that it is also annoying for others.
Since nobody complains, it might be the normal way of things for pulseaudio users.
Although, of course, it might be a security problem.

The /etc/udisks2/mount_options.conf should be tested and verified.

Umask
_https://en.wikipedia.org/wiki/Umask
_https://wiki.archlinux.org/title/Umask

$ umask
0022

_https://www.linuxquestions.org/questions/linux-general-1/mounting-ntsf-drive-in-fstab-unsure-of-fmask-and-dmask-values-4175458533/#post4934200

fmask, dmask, and umask taken together pertain only to Windows filetypes ( NTFS and FAT32 ) whereas umask alone pertains to both windows and Linux filetypes but are implemented 2 different ways.

On Linux Filesystems

At the moment of birth every file has permissions of 666 and every directory has permissions of 777. A system wide umask is created to modify these permissions immediately after birth and it's currently set at 002. So when you create a new file it's permissions are:

666
002 <-- minus the umask
==
664

And every new directory has permissions of:

777
002 <-- minus the umask
==
775

On Windows Filesystems

Windows fileystems have no Linux file permission attributes so a virtual filesystem is used to create a "view" to give them the appearance that they do have them. The system wide umask has no affect on these filesystems nor does a chmod or a chown. They can only be set when the "view" is created in fstab.

At the moment of birth NTFS files and folders start out with exactly the same permissions: 777. If you were to set up in fstab a umask of 002 for these partitions then the result would be different from a Linux filesystem:

File: 777 - 002 = 775
Folder: 777 - 002 = 775

The folder setting is fine and that's the way you want them to be but the files have all been made executable - every single one of them. You can change that by separating umask into it's constituent parts: fmask and dmask:

So if you set up fstab this way for an NTFS partition: dmask=002,fmask=113

File: 777 - 113 = 664
Folder: 777 - 002 = 775

_https://thelinuxcode.com/automount-usb-ubuntu/
_https://www.freedesktop.org/wiki/Software/udisks/
_https://storaged.org/doc/udisks2-api/latest/mount_options.html
_https://www.kernel.org/doc/Documentation/filesystems/vfat.txt

ArchWiki
_https://wiki.archlinux.org/title/Udisks#NTFS_mount_failing
_https://wiki.archlinux.org/title/Udisks#NTFS_file_creation_failing_(filename-dependent)

$ locate udisksd
/usr/libexec/udisks2/udisksd
/usr/share/man/man8/udisksd.8.gz

$ man udisksd
$ man udisksctl

Re: Automounting USB Drives (NTFS, exFAT) with dmask=022,fmask=133

dummy@example.com (PedroReina) — Tue, 10 Sep 2024 08:53:11 +0000

After 20 years, at last I know how to fix this annoying behaviour. Thanks a lot!

Automounting USB Drives (NTFS, exFAT) with dmask=022,fmask=133

dummy@example.com (igorzwx) — Mon, 09 Sep 2024 11:30:53 +0000

System: Devuan, Mate Desktop

$ cat /etc/*-release | grep PRETTY
PRETTY_NAME="Devuan GNU/Linux 5 (daedalus)" 

$ inxi -S
System:
  Host: devuan Kernel: 6.1.0-25-amd64 arch: x86_64 bits: 64 Desktop: MATE
    v: 1.26.0 Distro: Devuan GNU/Linux 5 (daedalus)

When you insert a USB drive, it is automatically mounted to a directory under /media
However, if your USB drive has a Windows file system (e.g. NTFS, or exFAT), all your text files (and all other files: *.jpg, *.wav, etc.) on the USB drive become executable (777 - 022 = 755).
If you copy such files to your home folder, you have to fix permissions, for example:

$ chmod -Rv -x+X -- ./

_https://unix.stackexchange.com/questions/296967/how-to-recursively-remove-execute-permissions-from-files-without-touching-folder

It seems that this problem can be easily fixed with /etc/udisks2/mount_options.conf

$ ls -1 /etc/udisks2/
mount_options.conf.example
udisks2.conf 

$ sudo nano /etc/udisks2/mount_options.conf
 
$ cat /etc/udisks2/mount_options.conf
[defaults]
vfat_defaults=uid=$UID,gid=$GID,shortname=mixed,utf8=1,showexec,dmask=022,fmask=133
exfat_defaults=uid=$UID,gid=$GID,iocharset=utf8,errors=remount-ro,dmask=022,fmask=133
ntfs_defaults=uid=$UID,gid=$GID,dmask=022,fmask=133

NOTE: /etc/udisks2/mount_options.conf is enabled automatically (a reboot is not required).
You can simply insert your USB drive and check file permissions:

$ touch file.txt
$ stat -c %a file.txt
644
$ mkdir folder1
$ stat -c %a folder1
755

See:
_https://chmodcommand.com/chmod-644/
_https://chmodcommand.com/chmod-755/

Perhaps, this mount_options.conf can be somehow improved, or there is a better solution.