Created attachment 455629 [details] udisks-fix-exec.patch Description of problem: It's an annoying problem with vfat/ntfs USB removable medias (flash memory sticks, USB HDD) when all files become executable by default. This creates unnecessary obstacles to open some files (e.g. *.txt, *.pdf) in Nautilus, since it's asking about whether to open or execute the file. The files copied to a local HDD usually needs 'chmod -x'. Version-Release number of selected component (if applicable): udisks-1.0.1-4.fc13 How reproducible: Each time a removable disk is inserted. Steps to Reproduce: 1. Connect a removable (e.g. USB) drive 2. List files from directory the udisks has mounted the media to Actual results: All files (including *.txt, *.pdf) become marked as executable. Expected results: The files should not be marked as executable until they are really executable Additional info: The issue is already fixed in udisks git: http://cgit.freedesktop.org/udisks/commit/?id=7e7ec1abca069e9443f8eed49acec4ea32589d0c http://cgit.freedesktop.org/udisks/commit/?id=f08f24ad0de4aefc55941f9a2f963c54f8696f18 So the bug is for backporting these fixed to the current Fedora release. Attaching the cumulative patch that adds these 2 backports and updates .spec file. The patch should be applied over extracted udisks-1.0.1-4.fc13.src.rpm Tested on Fedora 13 x86_64: $ uname -a Linux vkuzmichev 2.6.34.7-56.fc13.x86_64 #1 SMP Wed Sep 15 03:36:55 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux $ mount | grep JETFLASH /dev/sdb1 on /media/JETFLASH type vfat (rw,nosuid,nodev,uhelper=udisks,uid=500,gid=500,shortname=mixed,dmask=0077,utf8=1,showexec,flush) Related bugs: https://bugs.launchpad.net/ubuntu/+source/udisks/+bug/14335 http://bugs.freedesktop.org/show_bug.cgi?id=28075
Hmm, was running into that issue, too. Looks like there have not been a new udisks release after 1.0.1 which is what we have in F13 and F14. Would be great to either include this patch or if we could get a new udisks release...
Unfortunately it seems like this has been "fixed" in udisks 1.0.2 in F14 by using the "showexec" mount option by default. That is a regression for some usage scenarios. I think adding showexec is the worst possible solution to the problem. I think it is a bug in nautilus & friends that they are so willing to execute any executable file. The x bit indicates IMHO that the file might be executable, not that it has to be executed and not that it necessarily can be executed. I kind of agree that executing files from user-mounted devices should be disabled by default because of the security implications. But I find it very odd and wrong on a linux system to give windows executables the x bit. Windows executables are no more and no less secure than native sh/binary files, and we shouldn't care much about them. More important: People will soon figure out how to rename their (trojan) linux executables to .exe and thus re-introduce the security issue and render the showexec hack worthless.
>I think it is a bug in nautilus & friends that they are so willing to execute any executable file. Whaaat? Why do you think that nautilus should not execute executable files? Nautilus does not decide to mark files as executable! This flag is reported from FS driver. So this is a bug in a utility that mounts vFAT with such weird options. >The x bit indicates IMHO that the file might be executable, not that it has to be executed and not that it necessarily can be executed. The x bit indicates to the system that the file is executable. It's user's feature. It allows user to tell the system that the file could be run. The system should NOT make guesses whether it will or won't be executed. The system should execute executable files when the user want this!
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.