Can not run .exe .com and .bat from NTFS formated USB flash drive

[Leonardo Borda]

1. Description of the problem:

Currently NTFS formated USB flash drives do not have the exec bit for {exe,com,bat}. Use of NTFS makes more sense for some users , as pen drives tend to have larger capacities than earlier .

"vfat" support 'showexec' mount option, which is currently not implemented on ntfs-3g.

The use case is necessary when we have applications that are multi platform.

2. How reproducible is the problem?
Always. Format a usb key with NTFS and copy some .exe files. Insert it to the usb port and let Nautilus open it.
Files won't have the +x bit enabled.

drwxr-x---+ 4 root root 4096 Mar 11 16:11 ..
-rw------- 1 user1 user1 29 Mar 8 14:20 aaa.exe

3. Workaround
You can umout and mount manually with the following command. But it defeats the purpose of having proper permissions from the start.

sudo mount -t auto /dev/sda1 /media/lborda/

4. Additional info:

* ntfs-3g allows for exec mount option, which enables execute bit for all files.
* We would also need to enable "showexec" bit in udisk for ntfs, or allow for https://bugs.freedesktop.org/show_bug.cgi?id=33461

[Olivier Fourdan (fourdan)]

Created attachment 42455
Proposed patch (against current git)

gnome-mount had a feature to specify mount options per file system types (via GConf key "/system/storage/default_options/<fs type>/mount_options") that could be used to restrict read-only mount of removable devices from the desktop.

I could not find something similar with udisks (maybe it's there but I could not find it) so I wrote the attached patch to add this feature.

Basically, udev sets a property UDISKS_MOUNT_OPTIONS (coma separated list of options to pass to mount) that is read by udisk-daemon and appended to the options used to mount the device.

The idea is to allow sysadmins to force some mount options on some devices, for example "ro,noxec" on USB sticks.

[Olivier Fourdan (fourdan)]

There is a DBUS mechanism to pass mount options to udisks-daemon (used by udisks, the command line tool) but that may not really be what is needed here.

To get the desired mount options to be applied, that would require to implement the functionality in every desktop/file manager which may use usdisks (instead of forcing the options in udisks-daemon as done with the proposed patch).

Also, a user may use the udisks command directly without specifying the mount options to get the mount in read-write mode.

[Zeuthen (zeuthen)]

If you look at the FSMountOptions structure

 http://cgit.freedesktop.org/udisks/tree/src/device.c?id=1.0.2#n5843

then there are two arrays: defaults and allow. I think it would make sense to control both on a per-device basis via udev via, say. UDISKS_MOUNT_OPTIONS and UDISKS_MOUNT_OPTIONS_ALLOW. The former would be appended to the existing mount options (as you suggest) and the latter would be replacing it (to allow complete lockdown).

Then your use case will be just setting

 UDISKS_MOUNT_OPTIONS="ro,noexec"

Regarding the patch: I don't think we need to expose this a D-Bus property. Also, the patch should also include a modification to the udisks(7) man page.

[Zeuthen (zeuthen)]

Btw, the docs will have to be very careful about emphasizing that whatever the user set the properties to, may be filesystem dependent. An example like this might suffice

 # use specific charset for FAT filesystems
 #
 ENV{ID_FS_TYPE}=="vfat", ENV{UDISKS_MOUNT_OPTIONS}="utf8=0,iocharset=iso8859-15"

and the USB example in your patch is too encompassing (it sets the property on too many devices). It should be something like this

 # mount all USB devices RO
 #
 SUBSYSTEMS="usb", ENV{ID_FS_USAGE}=="filesystem", ENV{UDISKS_MOUNT_OPTIONS}="ro"

instead (and even this may be too wide - for example, the disk controller may be USB but the disk itself is something else. But that's unimportant.)

[Olivier Fourdan (fourdan)]

Sorry for the delay (got busy with other stuff), thanks a for the feedback! I am working on a new patch based on comment #2

[Olivier Fourdan (fourdan)]

(In reply to comment #2)
> If you look at the FSMountOptions structure
>
> http://cgit.freedesktop.org/udisks/tree/src/device.c?id=1.0.2#n5843
>
> then there are two arrays: defaults and allow. I think it would make sense to
> control both on a per-device basis via udev via, say. UDISKS_MOUNT_OPTIONS and
> UDISKS_MOUNT_OPTIONS_ALLOW. The former would be appended to the existing mount
> options (as you suggest) and the latter would be replacing it (to allow
> complete lockdown).

So I have implemented the UDISKS_MOUNT_OPTIONS_ALLOW which replaces the allow[] array set in the various FSMountOptions predefined structures (depending on the filesystem type), but then I am facing a problem because if the mount options defined in the defaults[] array are not listed in the allow[] one, then the mount is denied ("Mount option is not allowed").

For example, vfat_defaults[] lists the option "showexec". imagine a sysadmin does not want that option to be allowed, (s)he would not list that option in UDISKS_MOUNT_OPTIONS_ALLOW but then all devices using vfat will be denied the right to be mounted (which is not what most people want, I guess most people would want to use only the elements in the intersection of the two sets, {defaults[] ∪ mount_options[]} ∩ allow[] if that makes any sense :)

So I'll probably propose the two patches, yet I believe UDISKS_MOUNT_OPTIONS_ALLOW would be used to filter out the options that a sysamin does not want to be used (ie if not listed in UDISKS_MOUNT_OPTIONS_ALLOW, it is not passed to mount, rather than not allowing the mount).

> Regarding the patch: I don't think we need to expose this a D-Bus property.

Oops, sorry I can't find where it is exposed via D-Bus.

[Olivier Fourdan (fourdan)]

Created attachment 43436
Updated patch

That the patch I am not too happy with. Basically, if an option is used while not listed in UDISKS_MOUNT_OPTIONS_ALLOW (if set, of course) then the mount is rejected.

[Olivier Fourdan (fourdan)]

Created attachment 43437
Another proposed patch

This is the 3rd approach, which I think is better, UDISKS_MOUNT_OPTIONS_ALLOW is used as a filter, if an option is used but not listed in UDISKS_MOUNT_OPTIONS_ALLOW (if set, of course), then that option is ignored yet the mount is performed.

This allows the sysadmins to specify the exact subset of mount option to be allowed, so that options such as "showexec", for example, which is set by default on vfat can be filter out if needed.

[Orion-cora (orion-cora)]

This looks pretty stalled. I really need to be able to turn off "showexec" on out vfat mounts. Any hope for this in the future?

[Martin Pitt (pitti)]

vfat has the nice "showexec" option which automatically sets the executable bit for *.exe, *.com, and *.bat. But ntfs-3g does not have an equivalent option. One can add the "exec" mount option, but that will make _all_ files executable, and thus make it very confusing to open documents from NTFS devices (it would try to execute e. g. a Word document, which will obviously fail). As handling documents, media files etc. is far more common than trying to run DOS batch or Windows .exe files under Linux, udisks does not, and will not use "exec" by default.

You can locally work around this by adding the affected device to /etc/fstab (mount by label or UUID), and adding the exec option (and "noauto,user").

A better fix would be to teach ntfs-3g about a "showexec"-like mount option, which we could then use in udisks.

[Frederic Masi (fmasi)]

Hello Martin,

We have gone over the reasons why we will not have exec option set on vfat filesystem with the customer and at this point they get it. I will go over a bit more details on the use case bellow but what we are looking for right now is to have the showexec option added to ntfs support on precise.

Facts:

* The customer has 1000's of pendrive that have already being formated with ether ntfs or vfat.
* The pendrives belong to the individual users and there is very litre to no central management of such penrives.
  - This means they are extremely reluctent to consider the option of switching to a diffret file system like lets say UDF
* We need to be able to write and read from the pendrive in Windows and Linux (not only ubuntu)
* Customer is migrating all 80 000 desktops to precise
* The pendrive contains only one partition were all the data is located

Use Case:

We have a bunch of shell scripts that are created and stored in the pendrive and we need to be able to execute them in linux withought having to remount the file system or copy the data to the computer.

On any fat pendrive under Precise we simply change the shell scripts name to end with .com like that we are able to execute them withought any remount etc...
If only we could have a showexec feature with ntfs on precise we would be able to perform the exact same work flow and avoid having to format 1000's of pendrives.

Please let us know how feasable it is to implement the showexec feature for ntfs.

Sincerely
Frederic Masi

[Martin Pitt (pitti)]

A similar "showexec" option certainly can be implemented in ntfs-3g, it just takes someone with some experience with the ntfs-3g code and some time to do it. This should preferably be coordinated upfront with upstream in the forum or their developer mailing list (http://www.tuxera.com/community/ntfs-3g-faq/#bugreport) to get their input and help.

BTW, as another workaround you could just run scripts on these mounted drives through "sh /media/...".

[Frederic Masi (fmasi)]

It seems that upstream added a dmask fmask ntfs patch[1] that removes the X bit from all files, this actually will only make things worst for the use case described.

Any chance we can work on the showexec RFE for NTFS-3g and get it aproved upstream ?

[1] https://bugs.freedesktop.org/show_bug.cgi?id=28075#c5

Cheers
Frédéric Masi

[Ritesh Khadgaray (khadgaray)]

I believe, the user is looking for

Bug 33461 - Allow extra mount options from udev rules (edit)
https://bugs.freedesktop.org/show_bug.cgi?id=33461

[Stanislav Brabec (sbrabec-suse)]

Not knowing this bug, I created another patch:
http://lists.freedesktop.org/archives/devkit-devel/2015-April/001668.html

I like the idea here: configure mount options in the udev files.

But I would like to be able to do more: being able to configure selected mount options (e. g. exec/noexec, shortname, codepage, fmask, dmask, tz=UTC, time_offset,...) by a non-privileged user. It is now impossible.

Merging features of both together (udev support, non-privileged support, per-device, per-fs and per volume configuration) would create a very nice, flexible and comfortable solution.