http://bugzilla.opensuse.org/show_bug.cgi?id=1089408 http://bugzilla.opensuse.org/show_bug.cgi?id=1089408#c2 Stanislav Brabec changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbrabec@suse.com Assignee|sbrabec@suse.com |thomas.blume@suse.com --- Comment #2 from Stanislav Brabec --- mount has no influence to the desktop mount options. It only passes parameters from the mounting application (udisks2) to the kernel. In the case of exfat, kernel further passes options to FUSE. Reassigning to udisks2 maintainer. I am not sure, where the change between manual mount and automatic mount happens. Output of your mount command and udisks2 automatic mount are equal, but results are not. I suspect "default_permissions" mount option, probably with a different umask of calling task. Note: udisks2 itself defines (and hardcodes) per-filesystem mount options. In past, I wrote a patch that makes possible to configure mount options, but it was not included to the upstream: https://lists.freedesktop.org/archives/devkit-devel/2015-April/001668.html -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1089408 http://bugzilla.opensuse.org/show_bug.cgi?id=1089408#c5 George Anchev changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(studio@anchev.net | |) | --- Comment #5 from George Anchev --- Thanks for providing detailed info. Unfortunately even from the Debian bug report it is still not clear to me how to control the u/f/d/masks when external volumes are mounted. I see in the "Assigned to" link people complaining that it is hard coded and that as a whole the matter remains unresolved: https://bugzilla.gnome.org/show_bug.cgi?id=586708

What is the actual problem you are seeing with this? As outlined in the patch, the mount below a dedicated user directory already controls access to the files on the removable medium. There should be no need to set the permission for each particular file/directory on the medium.

It is essentially wrong to have 777 permissions by default for anything, especially for external volumes. Example scenario to illustrate why: Someone gives you a memory card/USB stick with some JPG images. Can a JPG file be an actual harmful code just named as file.jpg? - Yes. Perhaps not on Windows (which relies on extensions) but on Linux it can (which relies on file permission settings). Copying such a file to $HOME will still keep it executable. Would a non-executable permission provide additional protection in this case? - Yes. So should a JPG file be executable? - No. Along these lines: by default files on external volumes must not be executable. The parent mount point dir does control access by other users but it does not protect from the explained case. Second example: Some SD cards have a hardware write-protection lock. Mounting such a card and seeing that everything is writable is obviously wrong. So to my mind: this has both security and usability implications. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1089408 http://bugzilla.opensuse.org/show_bug.cgi?id=1089408#c10 George Anchev changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(studio@anchev.net | |) | --- Comment #10 from George Anchev --- Putting in /etc/fstab this:

/dev/sdf1 /run/media/ exfat rw,nodev,nosuid,noatime,uid=1000,gid=100,iocharset=utf8,errors=remount-ro,dmask=0077,fmask=1177

or this:

/dev/sdf1 /run/media/ exfat rw,nodev,nosuid,noatime,user,iocharset=utf8,errors=remount-ro,dmask=0077,fmask=1177

and rebooting (without having the physically mounted volume) results in: ... Aug 29 10:49:08 pc systemd[1]: dev-sdf1.device: Job dev-sdf1.device/start timed out. Aug 29 10:49:08 pc systemd[1]: Timed out waiting for device dev-sdf1.device. Aug 29 10:49:08 pc systemd[1]: Dependency failed for /run/media. Aug 29 10:49:08 pc systemd[1]: Dependency failed for Local File Systems. Aug 29 10:49:08 pc systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'. Aug 29 10:49:08 pc systemd[1]: local-fs.target: Triggering OnFailure= dependencies. Aug 29 10:49:08 pc systemd[1]: run-media.mount: Job run-media.mount/start failed with result 'dependency'. Aug 29 10:49:08 pc systemd[1]: dev-sdf1.device: Job dev-sdf1.device/start failed with result 'timeout'. Aug 29 10:49:08 pc systemd[1]: Starting Restore /run/initramfs on shutdown... Aug 29 10:49:08 pc systemd[1]: Reached target Sound Card. Aug 29 10:49:08 pc systemd[1]: Reached target Login Prompts. Aug 29 10:49:08 pc systemd[1]: Reached target Remote File Systems. Aug 29 10:49:08 pc systemd[1]: Reached target User and Group Name Lookups. Aug 29 10:49:08 pc systemd[1]: Reached target Host and Network Name Lookups. Aug 29 10:49:08 pc systemd[1]: Reached target Paths. Aug 29 10:49:08 pc systemd[1]: Reached target Network. Aug 29 10:49:08 pc systemd[1]: Reached target Timers. Aug 29 10:49:08 pc systemd[1]: Started Emergency Shell. Aug 29 10:49:08 pc systemd[1]: Reached target Emergency Mode. ... and I have to enter root password, comment out the line in /etc/fstab and reboot again so that I can login normally. So that approach seems to depend on the presence of the physical media which is a significant drawback. This:

udisksctl mount --block-device /dev/sdf1 --options dmask=0077,fmask=1177

works fine, giving the desired permission and ownership. But if I unmount/eject the volume, insert it again and click on it in Dolphin (which mounts it again) I still get 777 permissions. I suppose if there is a way to make these mounting parameters persistent that would be it.

Again, is this also shown when you do a user mount?

[~]: udisksctl mount --block-device /dev/sdf1 --options dmask=0077,fmask=1177 Mounted /dev/sdf1 at /run/media/<myusername>/EOS_DIGITAL. [~]: cat /proc/mounts | grep sdf1 /dev/sdf1 /run/media/<myusername>/EOS_DIGITAL fuseblk ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0 /dev/sdf1 /var/run/media/<myusername>/EOS_DIGITAL fuseblk ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1089408 http://bugzilla.opensuse.org/show_bug.cgi?id=1089408#c13 --- Comment #13 from George Anchev --- Thanks for the info. This: /dev/sdf1 /run/media/ exfat rw,nodev,nosuid,noatime,user,iocharset=utf8,errors=remount-ro,dmask=0077,fmask=1177,noauto,nofail results in a normal boot. However when I insert the memory card in the reader and click on its icon in Dolphin it says: Could not enter folder /run/media. Having a closer look reveals that the owner of files and dirs is root:root (not <myusername>:users as expected). Does that mean that the 'user' mount option has a bug too? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1089408 http://bugzilla.opensuse.org/show_bug.cgi?id=1089408#c15 --- Comment #15 from George Anchev ---

In my opinion, the default mask should be equal to the mask used by the user (or mounting process): 644 or 755.

In my case: [~]: grep umask ~/.bashrc umask 0077 I think this user choice should be respected rather than a generic 644 or 755.

Removal of executable flag is disputable. It is good for importing of photos, but makes impossible to start executables from VFAT.

And the question is: in what situation would one want to execute files from external VFAT? Would such desire justify to make everything executable by default? What overall consequences this may have and is it really worth to create insecurity by default for the sake of having a little convenience for the rare cases? An expert or at least a somewhat security minded person would never execute unverified file. A layman would do whatever is convenient, even not knowing what he is doing - that can be dangerous + it can affect other users on the system (even if they are security minded, especially in a post-Spectre/Meltdown world). If the system does not protect from such activity for the sake of a little convenience, we can as well run `sudo chmod 777 root:root /` (or go back to Windows and work as admin the whole time). That said: if the goal is the convenience to have executable flag by default, that should also be possible but it should be an "opt-in" configuration with explicit warning informing the user of the possible consequences. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1089408 http://bugzilla.opensuse.org/show_bug.cgi?id=1089408#c19 --- Comment #19 from Stanislav Brabec --- George Anchev, comment 17: If you want to use udisks, then don't add records to fstab. Mounting volumes from fstab is supported by udisks2 as well, but it does not happen automatically when the device is inserted. Yes, there is something strange with udisks2 support in XFCE. Some devices are auto-mounted (camera VFAT flash disks), some are not (multi-partition USB HDD). -- You are receiving this mail because: You are on the CC list for the bug.