1005948 - Firefox on Linux warns about downloaded files being executable even when opening them with helper apps

Status: NEW

(Firefox :: Downloads Panel, defect)

Description

[sc7898]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140428193813

Steps to reproduce:

Downloaded a .rar or .jpg or .txt file (seems to happen for any file type) and open it from within the downloads button drop-down menu.

OS: Linux/Ubuntu 14.04 x64


Actual results:

I am presented with the "[Filename] is an executable file. Executable files may contain viruses. [...] Are you sure you want to launch [Filename]" warning. I am not presented with the warning when choosing 'open' instead of 'save' from the download prompt itself.


Expected results:

The file should have opened immediately. Rar and JPEG files are not executable.

Comment 1

[:Gijs (he/him)]

Funnily enough, a bunch of this stuff recently surfaced in a newsgroup thread [0]. AIUI from that thread, this behaviour shouldn't currently be happening. Zack/Ralph/Mike, do you have input on why it would be? :-)


[0] https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/Vtjy0KMa4LE

Comment 2

[Zack Weinberg (:zwol)]

The current (Unix/Mac) download code, as far as I can tell, never sets the execute bit on downloaded files, which means *our code* should not be causing this problem.  But I can think of one possible way it could be happening anyway: All files on a (V)FAT file system are considered to be executable, because that filesystem doesn't natively support execute bits. This may also happen for NTFS depending on how it's mounted.

Reporter: we need to see the output of the following commands. I'm not familiar with recent Ubuntu, but look for a program named "Terminal" in the applications menu or whatever equivalent you have.  Type the next two lines EXACTLY AS SHOWN into that window, and copy and paste the UNEDITED output into the bug, please.

mount
ls -l ~ ~/Downloads ~/Desktop $TMPDIR /tmp /var/tmp

Comment 3

[Ralph Giles (:rillian)]

I don't see this with Nightly on Fedora. Zach's point is a good one.

Comment 4

[sc7898]

Your guess about the filesystem is right Zach. It's NTFS, symbolically linked to a partition mounted in fstab. Output of your command for the folder in question is:

lrwxrwxrwx 1 [Username] [Username]    35 Apr 25 11:40 Downloads -> /storage/Personal Folders/Downloads

I tried it on an ext4 partition folder and the problem did not occur.

Comment 5

[sc7898]

*as in, the Linux downloads folder is symbolically linked to one shared with Windows.

Comment 6

[Zack Weinberg (:zwol)]

Thanks for the info.  There's not much Firefox can do about the "every file is executable on NTFS" phenomenon, but, digging around a little, I think we can at least avoid the inconsistency between opening the file directly and opening it from the completed-downloads list.  The implementation of "open file from completed-downloads list" appears to be here:

https://mxr.mozilla.org/mozilla-central/source/browser/components/downloads/src/DownloadsCommon.jsm#436

... and you can see that it does the "if executable, prompt" check *before* the "is this something we send to a helper application" check.  I'm not finding the implementation of "open file directly upon download" right now (too tired to think of good keywords) but I bet it does those checks in the opposite order.

Comment 7

[:Gijs (he/him)]

(In reply to Zack Weinberg (:zwol) from comment #6)
> https://mxr.mozilla.org/mozilla-central/source/browser/components/downloads/
> src/DownloadsCommon.jsm#436
> 
> ... and you can see that it does the "if executable, prompt" check *before*
> the "is this something we send to a helper application" check.  I'm not
> finding the implementation of "open file directly upon download" right now
> (too tired to think of good keywords) but I bet it does those checks in the
> opposite order.

This makes sense to me. Moving to DL panel (toss up between that and file handling, but that says "not for download manager bugs, file those in toolkit - except this code is clearly not in toolkit...) and backlogging this - this seems like low-hanging papercut stuff that we should be fixing soon.