Ubuntu

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

Reported by Ryan Lortie on 2005-03-21
254
This bug affects 36 people
Affects Status Importance Assigned to Milestone
Nautilus
Won't Fix
Medium
One Hundred Papercuts
Low
Unassigned
udisks
Fix Released
Wishlist
Baltix
Undecided
Unassigned
pmount (Ubuntu)
Undecided
Unassigned
udev (Ubuntu)
Undecided
Unassigned
udisks (Ubuntu)
Low
Martin Pitt

Bug Description

I just got a new USB drive. It's pretty spiffy.

Whenever I plug it in it automounts and appears on my desktop. That's also
pretty spiffy.

The problem comes in two parts:

1: The filesystem is mounted with a set of options that cause all files on the
vfat drive to be marked executable (ie: the kernel default).

2: When you double-click an executable but otherwise recognised file in
nautilus, you get 'Do you want to run "file.abw", or display its contents?'.

I don't ever want to execute an Abiword document.

So either the defaults (in pmount?) need to be modified to change the file mode
mask for vfat filesystems or nautilus needs to be patched to not ask this
question all the time.

http://bugzilla.gnome.org/show_bug.cgi?id=322868: http://bugzilla.gnome.org/show_bug.cgi?id=322868

Sebastien Bacher (seb128) wrote :

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

Sebastien Bacher (seb128) wrote :

That only happens for text files in fact

Sebastien Bacher (seb128) wrote :

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

Sebastien Bacher (seb128) wrote :

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

Changed in nautilus:
assignee: seb128 → desktop-bugs
status: Unconfirmed → Confirmed
Changed in nautilus:
status: Unconfirmed → Confirmed
Mike Trim (miketrim) wrote :

(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.

Colin Watson (cjwatson) wrote :

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.

Mike Trim (miketrim) wrote :

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.

Changed in nautilus:
status: Confirmed → Triaged

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

Mike Trim (miketrim) wrote :

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.

jamesmcm (jamesmcm03) wrote :

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.

roffik (roffik) wrote :

@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:\

Przemysław Kulczycki (azrael) wrote :

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".

Przemysław Kulczycki (azrael) wrote :

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

Przemysław Kulczycki (azrael) wrote :

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

Przemysław Kulczycki (azrael) wrote :

Possible duplicate: Bug #391263

summary: - 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: - 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
Przemysław Kulczycki (azrael) wrote :

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

Changed in hal (Ubuntu):
status: New → Confirmed
Changed in udev (Ubuntu):
status: New → Confirmed

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.

Przemysław Kulczycki (azrael) wrote :

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.

affects: hal (Ubuntu) → pmount (Ubuntu)
Changed in udev (Ubuntu):
status: Confirmed → Invalid
Przemysław Kulczycki (azrael) wrote :

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

One problem of using vfat devices on linux has always been that all files are executable by default, to accomodate the tiny use case of having shell scripts, and Windows exe files executable (through wine or CLI). However, this is a rather huge pain for all other files, since nautilus will keep asking you about whether to open or execute the file, even if it's just a .txt or .mp3.

We recently discovered that the vfat fs actually provides a nice kludge for this:

http://www.kernel.org/doc/Documentation/filesystems/vfat.txt (search for "showexec")

So with the showexec mount option we have sensible permissions for data files, while retaining the x bit for .exe, .com, and .bat, thus emulating windows' behaviour very closely.

I just committed a test case which tests sensible dir and file permissions for all but the known-broken ntfs and vfat:

http://cgit.freedesktop.org/udisks/commit/?id=a7effbab11fb5a5d81b810a1cb3b29864bfde575

My proposal is to add the "showexec" mount option by default (or at least to "allowed") for vfat. The proposed patch removes "vfat" from the list of known-broken file systems, the test case now passes for vfat.

Created an attachment (id=35592)
proposed patch

proposed patch

The current downside of this is that shell scripts would stop working on vfat. So this requires deciding about the trade-off about sensible data files (which seem to be a majority) and being able to run scripts off vfat devices (which is by and large interesting for developers)

GreatBunzinni (greatbunzinni) wrote :

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.

Martin Pitt (pitti) wrote :

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

affects: nautilus (Ubuntu) → udisks (Ubuntu)
Changed in udisks (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Martin Pitt (pitti)
status: Triaged → In Progress
Changed in pmount (Ubuntu):
status: Confirmed → Invalid

(In reply to comment #1)
> Created an attachment (id=35592) [details]
> proposed patch
>
> proposed patch
>
> The current downside of this is that shell scripts would stop working on vfat.
> So this requires deciding about the trade-off about sensible data files (which
> seem to be a majority) and being able to run scripts off vfat devices (which is
> by and large interesting for developers)

Looks good to me. Please commit. Thanks.

Pushed, thanks for review.

Martin Pitt (pitti) wrote :
Changed in udisks (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in udisks (Ubuntu):
status: Fix Committed → Fix Released

Martin, what about NTFS? In the mean-time how about using a fmask to avoid files being marked as executable?

Vish (vish) wrote :

Carrying over papercut task from dup Bug #425166

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

Changed in hundredpapercuts:
importance: Undecided → Low
status: New → Fix Released
Changed in nautilus:
status: Confirmed → Won't Fix
Mihai Capotă (mihaic) wrote :

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

Mihai Capotă (mihaic) wrote :

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

Changed in udisks:
importance: Unknown → Wishlist
status: Unknown → Fix Released
Changed in nautilus:
importance: Unknown → Medium

Hi Martin,

are there plans to do a new udisks release? Would be great to have this fix included. In Fedora for example we are still with 1.0.1: https://bugzilla.redhat.com/show_bug.cgi?id=646673

Indeed that's been discussed already. So far I kept this on hold because there was some discussion about having to revert a patch which was not quite ready ("use bsg and ata_id instead of scsi_id"), but it turns out that this affected udev, not udisks. So I'll do an 1.0.2 release now.

Changed in udisks:
importance: Wishlist → Unknown
kaleidoscopeit (jaater) wrote :

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)

kaleidoscopeit (jaater) wrote :

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.

Changed in udisks:
importance: Unknown → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.