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 attachment 35592 [details] [review] 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)
(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, what about NTFS? In the mean-time how about using a fmask to avoid files being marked as executable?
Sure, my pleasure. http://cgit.freedesktop.org/udisks/commit/?id=f08f24ad0de4aefc55941f9a2f963c54f8696f18 works well for me.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.