nautilus wants to execute all text files on vfat and ntfs drives

we have fixed the same bug for warty, seems to be here again ...

That only happens for text files in fact

*** Bug 10646 has been marked as a duplicate of this bug. ***

I've forwarded the issue upstream: http://bugzilla.gnome.org/show_bug.cgi?id=322868

(copied from https://bugs.launchpad.net/ubuntu/+bug/161859):

[In gconf] /system/storage/default_options/vfat/mount_options on a clean install of gutsy/feisty has umask=0077, which makes all files +x. This means that files copied from a usb fat drive to the local drive will have the +x bit set, so Nautilus will always prompt for Run/Open.

Instead, mount_options should include fmask=0177 and dmask=0077 so that files are not +x.

This was the case in gutsy, I haven't tried hardy yet.

If you do that, then *no* files on a VFAT filesystem will be executable, which I expect a different set of people will find inconvenient.

It would only affect files on external drives, not fixed partitions that are mounted via fstab. I wouldn't have thought that many normal users would want to be executing files from external drives -- and if someone did want to run a script on an external drive they could just use sh /media/disk/whatever, or manually override the mount options for that drive in its properties window.

Either way, the current behaviour -- whereby opening any text file (in Nautilus) that is on or was copied from a vfat/ntfs drive displays a confusing message -- is not very helpful to new/non-technical users.

Also, if the user has chosen to always run executable text files in the file management preferences, then they could potentially inadvertently execute a malicious script located on a portable flash drive for example.

Until nautilus can in some other way distinguish between which files could want to be executed.....

surely the sane default for ubuntu to use would be to "view executable text files when they are opened" instead of "ask each time"
this will then be the default for all folders (even if not vfat/ntfs)

It should be the default as this is what noobish people would expect, who are also the people likely to still be using ntfs/vfat drives and therefore who are going to be prompted by this dialogue more. And as the experienced users are more likely to know how to change the setting to "ask each time" if that is what they want, and are more likely to keep their home directory where this setting would be saved, and are more likely to be using the terminal to execute these files anyway

lets not annoy the non-technical users

In the CD-ROM case (bug #353548), the workaround/fix for this is to add "mode=0444" to the following gconf key:
/system/storage/default_options/iso9660/mount_options

This results in all files on CD-ROMs being mounted without the executable flag set, unless the CD-ROM has Rock-Ridge extensions that specify the permissions. Note that this will not prevent explicitly executing scripts on the disc via an interpreter.

In my opinion, this setting and the similar ones for vfat/ntfs mentioned above should be the default. I cannot think of any use-cases where someone would want to directly execute files from an external drive or CD-ROM.

I think the best fix would be to make nautilus scan files for the shebang AND have executable permissions before asking. The issue is atm files copied from NTFS partitions, etc. have all permissions enabled and so it asks for execution on every file, checking for the #! is much better behaviour IMO. Whether this is feasible or not I do not know, but you are only looking at scanning the first few characters of the file.

@jamesmcm: yes yes yes!!! you're right, men! I was searching for a bug covering the problem with this function, and your fix is amazingly simple! I think that it should be fixed ASAP, because now Nautilus asks me if I want to execute an .ini file:/ And it doesn't, when I double click a bash script:\

Can anyone provide any good reason for leaving the executable bits on FAT and NTFS partitions?
It just makes people annoyed, especially new users coming from Windows and wanting to read something from their Windows partition.
If anyone wants to execute scripts from a FAT/NTFS partition then he can use "source filename" or "sh filename".
This would be a much better behaviour because no user would be tricked by some hacker to "open some cool file from his pendrive".

Another reason for changing the default umask: Bug #255391 nautilus-share shared ntfs/vfat folders cant be read over samba as ntfs/vfat fstab is umask=007

Another one: Bug #157094 USB mass storage devices are mounted with unsafe permissions

Possible duplicate: Bug #391263

from duplicate https://bugzilla.gnome.org/show_bug.cgi?id=601736
https://bugzilla.gnome.org/show_bug.cgi?id=322868

blueprints https://blueprints.launchpad.net/ubuntu/+spec/vfat-noexec

Good comment from bug #60722, worth copying here:

ceg (ceg: 2903) wrote on 2008-07-29: #4

You can make your fat filesystem permissions look like matching to your default umask.

Mount options:
for umask 002: dmask=002,fmask=113
 for umask 022: dmask=022,fmask=133
(do not use the unspecific umask option)

As a workaround adjust your personal hal vfat mount options in the gconf-editor, but the defaults need to be dealt with by ubuntu.

Other usefull mount options can be found on:
http://bugs.debian.org/344278

2010.04.21 22:45, Przemysław Kulczycki rašė:
> ** Summary changed:
>
> - nautilus wants to execute all text files on a vfat flash drive
> + nautilus wants to execute all text files on a vfat and ntfs drives
>
> ** Summary changed:
>
> - nautilus wants to execute all text files on a vfat and ntfs drives
> + nautilus wants to execute all text files on vfat and ntfs drives
>
>

According to comment #9, this also happens with iso9660 disks.

I've added the udev and hal (for Ubuntu <9.10) tasks because this issue has 2 possible solutions: change the behaviour of nautilus or change the default fmask/dmask on fat and ntfs.

Ok, partly ignore my last comment - it should be pmount.

I don't believe this problem is a Nautilus bug. The exec permissions are the same to Nautilus as they are to other file managers such as KDE's Dolphin. Moreover, this very same problem also affects any shell.

So, to put it in other words, the problem behind this is the poor choice for the default traditional UNIX permissions that are attributed to FAT (and maybe other) file systems which don't support traditional UNIX permissions. From there, File managers and the like are dragged down by this bug.

As per https://blueprints.launchpad.net/ubuntu/+spec/vfat-noexec this is most easily implemented in udisks now.

Pushed to upstream git head: http://cgit.freedesktop.org/udisks/commit/?id=7e7ec1abca069e9443f8eed49acec4ea32589d0c

This bug was fixed in the package udisks - 1.0.1-2

---------------
udisks (1.0.1-2) unstable; urgency=low

  * Add 00git-vfat-showexec.patch: Enable the "showexec" vfat mount option, to
    avoid data files being executable (which causes confusing question dialogs
    in nautilus which only have one sensible answer). Patch taken from
    upstream git head. (LP: #14335)
  * Add 00git-dont-probe-nondata-cdroms.patch: Don't probe non-data CD-ROMs
    for partition tables. Patch taken from upstream git head.
 -- Martin Pitt <email address hidden> Tue, 01 Jun 2010 10:31:47 +0200

Carrying over papercut task from dup Bug #425166

Finally, It had to be pitti Fixing this bug ;-)

The way I read it, the fix only applies to vfat. What happens to ntfs?

It looks like ntfs is also fixed in the latests udisks:
"- Do not have files executable on NTFS."

https://launchpad.net/ubuntu/maverick/+source/udisks/1.0.1+git20100614-1

What about simple ELF executables? They doesn't work anymore!
Futhermore the .exe files won't executes in the same way, because Wine tells me that this files are not marked as executable.

Now on Maverick you cannot run .exe and simple ELF executables

For me is a problem because I've done a work based on Wine witch I've called 'Wine Portables' : using the intresting concept from playonlinux I've builted a lot of 'portable software' in a self contained wine binaries+wineprefix folders and I use this 'portable' very often. This includes a lot of common software like Ms Office, Autocad, Photoshop, Google sketchup and a lot of click'n'run portables windows games.

I used to keep this software in an external hard-drive because I use this softwares both at home and at work.

A quick fix to make this type of software again playable is to include also ELF executables in the list of file types which have to marked as 'excutable'

Bye.

kaleidoscopeit [2011-02-14 11:10 -0000]:
> A quick fix to make this type of software again playable is to include
> also ELF executables in the list of file types which have to marked as
> 'excutable'

There is only a list in the kernel, and it's doing name based
matching. So what you could do is to append an ".exe" extension to
your ELF file?

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

For the real Windows executable (.exe) Wine notify me that the file are not marked as executable and the I've to copy this file on my internal storage and then set the execute bit on

For the ELF linux binary there's no way, if I rename it appending .exe the system try to execute this file via Wine but obviusly is not the right way

I've a bash script that add in the PATH environment variable the standalone Wine kit taken from Playonlinux e use this specific version for run a specific portable WINEPREFIX

Sadly Is mandatory to run ELF executable from the location where is stored the 'wine-portable' software and in this case the location is in an external storage.