GNOME Bugzilla – Bug 309862
The "Cannot open foo.bar" security warning dialog does not increase security
Last modified: 2008-10-18 14:21:57 UTC
I never want to Nautilus to tell me that it can't open a .wmv file because it's contents indicates it's a ASF stream ever again. Likewise for .mp3 vs. "audio/mpeg", .xml vs. HTML, and any other misidentification that you care to think of.
Thanks for your bug report! What version of Nautilus and GnomeVFS are you using? In recent unstable versions (2.11), this should have heavily improved, since we take subclassing into account when deciding whether to display that warning dialog.
2.10. You should probably disable the feature entirely until it's actually useful.
An actual blacklisting would be way more useful than whitelisting; as it is (particularly on linux) this is mostly just frustrating- I've never, ever gotten the warning in a case where it would have actually protected me from anything.
I think the intention was to protect against the case where a file was named with the wrong extension for its type. The user would look at the extension, mentally say "Oh, that's safe.", open it, and discover that GNOME used its magic number to determine its MIME type instead of its extension, and now some OpenOffice macro is eating their files or something. The problem is that this isn't useful from an end-user security POV, because end users a) aren't going to have any kind of understanding of the "safeness" of files and b) they shouldn't ever have to make these decisions anyway. Ideally, we'd be able to attach a "potentialy dangerous" xattr to every file created by the web browser/mail client/newsreader/etc. and then everything that opens files would check for that xattr and operate in paranoid mode if its found. Unfortunately, this requires kernel support (which probably won't happen in non-Linux land), apps setting the xattr when appropriate, apps recognizing the xattr and acting appropriately, the abscence of bugs, etc. and that's not going to happen. A different spin on the labeling of potentially dangerous files would be to add an extra verb ("Open Safely") that network-facing apps could use to open downloaded files, but all that really does is eliminate the need for kernel support (while opening up an unsafe pathway where a user could save a dangerous file to disk and then open it by some other means) and Nautilus/gnome VFS/whatever (to my knowledge) doesn't really support Windows Explorer-style verbs, anyway. So. Hard problem. Current solution is just unpleasant without actually doing anything.
Theres a similar bug here: https://bugzilla.ubuntu.com/show_bug.cgi?id=12844 with this comment: "Cannot open attachment.cgi.html The filename "attachment.cgi.html" indicates that this file is of type "HTML page". The contents of the file indicate that the file is of type "differences between files". If you open this file, the file might present a security risk to your system. Do not open the file unless you created the file yourself, or received the file from a trusted source. To open the file, rename the file to the correct extension for "differences between files", then open the file normally. Alternatively, use the Open With menu to choose a specific application for the file. Can this error dialog please die now (or at least be special-cased to only apply to situations where your computer is *actually* in danger)? It'd be great it Nautilus just did the reasonable thing and opened the file in either ephy or gedit. I can't really think of a case where opening a file like this could be a security problem (except in the case where the file is explicitly marked executable, and this could be handled as the special case). Certainly, in any case where Nautilus is about to execute a script (rather than open it in an editor) I'd like to be asked about it anyway. For the record, Nautilus has the following preference: Executable Text Files: ( ) Run executable text files when they are clicked. ( ) View executable text files when they are clicked. (o) Ask each time. <-- default. Even if I set this to "Run executable text files when they are clicked" and double click on a shellscript that has the extension ".sh" it opens in gedit because it lacks mode +x."
Note that in the case of docbook files, once one installs a mimesniffer so that they are properly identified as being distinct from .xml files, this dialog means you *can't open docbook files* from nautilus. Bumping priority because it forces me to use a terminal.
Luis: The "mime type foo doesn't work" kind of bug reports are NOTGNOME (shared-mime-info). Nevertheless, maybe you could send me a sample file by mail so that we can fix shared-mime-info? Or even better, maybe you could file a bug report at freedesktop.org and attach a sample file and CC me? An ironic aspect of this bug is that it is suitable for fine-graining shared-mime-info by hindering people from doing their work as long as the MIME info is broken.
Manny: I *have* fixed shared-mime-info, AFAICT; the sample file (and mime-type info file) are on nautilus-list. Nautilus's naive check of extensions still hoses me, though.
Created attachment 49800 [details] [review] Proposed patch to make Luis not rant Short explanation under [1]. [1] http://mail.gnome.org/archives/nautilus-list/2005-July/msg00290.html
I've committed a slightly modified version of the attached patch.
Fixed, closing.
*** Bug 315595 has been marked as a duplicate of this bug. ***
This still hoses me for the case where you save a patch off of bugzilla and it gets a .cgi extension. I've reopened the downstream Ubuntu bug and am reopening this bug accordingly. This message is non-sense in any case where my computer is not at risk (which it definitely isn't in this case): ----------------------------------------------------------------------- Cannot open attachment.cgi The filename "attachment.cgi" indicates that this file is of type "CGI script". The contents of the file indicate that the file is of type "differences between files". If you open this file, the file might present a security risk to your system. Do not open the file unless you created the file yourself, or received the file from a trusted source. To open the file, rename the file to the correct extension for "differences between files", then open the file normally. Alternatively, use the Open With menu to choose a specific application for the file. ----------------------------------------------------------------------- Nautilus should never launch a CGI script (it's not even marked executable). I'd expect both to be opened in gedit. There is no danger here.
oops. actually reopening :)
*** Bug 317234 has been marked as a duplicate of this bug. ***
This hoses me for more than 2 month. nautilus 2.13.93
In what context do you see it, in which distribution?
I get this one in the ubuntu development branch (dapper~flight6). I upgraded from gnome 2.12 to 2.14 with ubuntu, and now I get this when clicking a .jpg file: The filename "06_belle_sebastian.jpg" indicates that this file is of type "jpg-dokument". The contents of the file indicate that the file is of type "JPEG-bild". If you open this file, the file might present a security risk to your system. Do not open the file unless you created the file yourself, or received the file from a trusted source. To open the file, rename the file to the correct extension for "JPEG-bild", then open the file normally. Alternatively, use the Open With menu to choose a specific application for the file. Renaming to .jpeg actually works, but I don't accept that as a solution...
I'm running into this on Fedora Core 6 (Gnome 2.16) with Scribus documents. The Scribus FDO MIME Type definition is this: <?xml version="1.0" encoding="UTF-8"?> <mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info"> <mime-type type="application/x-scribus"> <comment xml:lang="en">Scribus Document</comment> <!-- [snip translations] --> <magic priority="100"> <match type="string" value="SCRIBUSUTF8" offset="0"/> </magic> <glob pattern="*.sla" /> <glob pattern="*.sla.gz" /> <glob pattern="*.scd" /> <glob pattern="*.scd.gz" /> </mime-type> </mime-info> Called scribus.xml and it's installed in /usr/share/mime/packages. I've run update-mime-database /usr/share/mime. When I try to open a .sla file, I get: The filename "Document-1.sla" indicates that this file is of type "Scribus Document". The contents of the file indicate that the file is of type "plain text document". If you open this file, the file might present a security risk to your system. [...etc...] Document-1.sla starts like this: <SCRIBUSUTF8NEW Version="1.3.3.4" > <DOCUMENT HalfRes="1" MAGMAX="3200" TextPenShade="100" MAJGRID="100" ABSTSPALTEN="11"... Any ideas about how to work around this? Thanks, Taj
Can't you just add a "execute anyway"-button in the dialog??
(In reply to comment #20) > Can't you just add a "execute anyway"-button in the dialog?? > That doesn't do anything to solve the problem. A .wmv/.wmv file is an ASF container. A .mp3 file is (possibly) an MPEG container (more likely an ID3v2 container, these days). Likewise for MS Office documents (.doc/.xls/etc. verses the generic OLE structured storage container that they use), OpenOffice (.sxw vs. Zip), Java JARs (Zip, again), etc. Sticking in an "Do what I mean" button because Nautilus is too stupid to do what I mean is not a solution to the problem.
well the problem is that i can't open the files so that would solve the problem. why not removing this "feature"?
Still not fixed in 2.16.2 It complains about opening .html which is actually XHTML (xml). Sustaining Luis' comment #3 - please remove this "feature"
The same thing happens with .exe files. I have WINE installed, and it is set to handle .exe extensions, but Instead I get "The filename "launch.exe" indicates that this file is of type "executable". The contents of the file indicate that the file is of type "DOS/Windows executable". If you open this file, the file might present a security risk to your system. Do not open the file unless you created the file yourself, or received the file from a trusted source. To open the file, rename the file to the correct extension for "DOS/Windows executable", then open the file normally. Alternatively, use the Open With menu to choose a specific application for the file. " It's not just with .cgi or .ini files. The whole mimetype system is broken. It never used to do this before I upgraded to 2.14.
Can we expect to see a fix for this problem soon? I mean, it has been almost two years since the problem was first reported, and it's still present in 2.16.3. Is this perhaps fixed in 2.18?
No, it's still not fixed 2.18. However, a workaround is discovered is adding: <sub-class-of type="base-type" /> to the MIME Type in the .xml file makes the warning go away. For example, for Scribus files (which are SGML files that Gnome detects as plain text/open me with GEdit), adding: <sub-class-of type="text/plain" /> fixed the problem (after running update-mime-database).
Any news on why this has now been an active bug for a couple of years? Is there a way of removing the dialog completely without diving into the code? Ideally I would like a solution that could persist accross versions so I do not have to find the relevant chunk of code in each release and change every time I upgrade. I only notice this issue when playing back wmv files but it is thoroughly useless by now as I just always assume it is a false positve. I expect most other users do the same.
I figured out the workaround/ fix for the underlying problem, (though the bug as far as nautilus is concerned is that it's either too smart or not smart enough in handling mime types) and I hope this may shed some light for the nautilus developers to come up with the appropriate fix. In my case, (and I am using fedora 6) the freedesktop.org.xml file in /usr/share/mime/packages lists the .exe extension as belonging to the "x-executable" mime type, when it should rather be "x-ms-dos-executable" and the Description field lists executable, instead of "DOS/Windows executable". This seems to conflict with the mime types nautilus is reading elsewhere, like in some /usr/share/applications/?.desktop file, I think. Here is what the freedesktop.org.xml section looks like (with out the language stuff): <code> <mime-type type="application/x-executable"> <comment>executable</comment> <magic priority="40"> <match value="\177ELF" type="string" offset="0"> <match value="1" type="byte" offset="5"> <match value="2" type="little16" offset="16"/> </match> </match> <match value="\177ELF" type="string" offset="0"> <match value="2" type="byte" offset="5"> <match value="2" type="big16" offset="16"/> </match> </match> <match value="MZ" type="string" offset="0"/> <match value="0x521c" type="little16" offset="0"/> <match value="0420" type="host16" offset="0"/> <match value="0421" type="host16" offset="0"/> <match value="0603" type="little16" offset="0"/> </magic> <glob pattern="*.exe"/> </mime-type> </code> The fix (workaround) that works for me is to edit /usr/share/mime/packages/freedesktop.org.xml (as root) and change the following lines: <code> <mime-type type="application/x-executable"> <comment>executable</comment> </code> change to <code> <mime-type type="application/x-ms-dos-executable"> <comment>DOS/Windows executable</comment> </code> Once this has been done, you need to run (as root): "update-mime-database /usr/share/mime" This should correct the problem. Other filename extensions can get mixed up too, but the fix should basically be the same. Check the /usr/share/mime/packages directory for references to the wonkified extension or mime type and then edit the offending file to correct it. Once done, run the update-mime-database command to apply the changes to the system and bob's your uncle. Nautilus seems to get screwed when it gets conflicting information about mimetypes from different files. Nautilus needs a better way fo handling these conflicts, and gnome in general needs a more unified approach to mimetype definition.
I'm not very familiar with the code and the mime-type system and I have no idea what this mime-share-info means, but: Why not associate the filename's extension (e.g. '.php') with several mime-types? I get the problem for a PHP-script that looks like an HTML-document (well, duh), so, why not tell nautilus that PHP-scripts (detected by examining filename) can actually be of mime-type HTML, XHTML, text files, etc... Also, I think the bug resolution should be seperated to text files and binary files: As for my PHP/HTML problem it can be resolved with loading the file into gedit or any text editor. This is not a security risk when the files are regular text files (unless there's some ultra-hax0r-bug when reading text files on the text editor software but that's not related here). As for binary files, such as the ".wmv" problem, a different solution should be made, because you don't want to open binary files on gedit. That's why I think this bug should be solved once for text files (should be easy I guess) and once for binary files (I don't open '.mwv' files so I don't really care right now).
I'm getting this with javascript "*.js" files... ======= The filename "Textpandable.js" indicates that this file is of type "JavaScript program". The contents of the file indicate that the file is of type "C source code". [blah blah blah...] ======= Please note that while some blame rests on https://bugs.freedesktop.org/show_bug.cgi?id=11837 ("JavaScript detected as C source), this "secure dialog" appears to be contentious at best, with numerous cases where it unnecessarily activates. As has been correctly pointed out, all these false-positives completely negate any benefit it may provide if/when it ever actually detects a valid problem. So until there is a day where the mime-type resolution issues are completely bug free (a day that is highly unlikely to _ever_ come!), the feature should either be removed, or users should have a way to disable it if needed - either on a per-file-extension basis, or across the board. Let me just add that as a user, it's intensely frustrating to put the effort into looking for a solution to something like this, only to discover that it's been a known issue for two years, and that very reasonable requests for workarounds have been actively resisted. Please, this is a non-trivial usability issue that must be addressed. The exact details of "how" are much less important than the "when".
It is infuriating to double-click on a CGI script and get an error that says "Sorry, that's not a CGI script, it's a Perl script!" Obviously the MIME info is screwed up somewhere, and needs to be fixed, but the fact is that Nautilus' behavior here is broken. I've already explicitly gone into the file's Properties, to the "Open With" tab, and set an application to use for "files of type Perl script". And I've already gone into the File Management Properties and set "view executable text files every time." But does Nautilus honor my preferences? No, it completely ignores them. It assumes that I don't know what I'm doing, and furthermore it assumes that IT actually knows better than I do what I want. I expect that kind of garbage from Microsoft Office; I don't expect it from Gnome. When I explicitly configure Nautilus to behave a certain way, and it fails to do so, that's broken, and it's infuriating in this case. Don't try to outsmart me Nautilus, just do what I say! Also: the version on this bug is set to 2.11.x, and the Gnome version is set to 2.15/2.16. Would it help this bug get more attention if those were updated?
the nautilus gio version doesn't display such warning on usual cases, the bug can likely be closed
Closing as OBSOLETE then.