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

Four years later and nothing has happened. Where can I find the sources responsible for this insane behavior?

(In reply to comment #0)
> This has, of course, large security implications and shouldn't be
> light-heartedly adopted. A lot of people just press OK every time a dialogue is
> opened, and this would provide an easy way to sneak in for malware. 

A lot of people also just go to Properties -> Permissions -> Allow executing file as program without further consideration. An idiot is always an idiot, you cannot force a security awareness on someone just by making it hard to run something. A user wanting to run an executable will find a way of running it anyhow. He'll just Google how to do it. There's nothing to this, it's just policy bullshit standing hindering a normal workflow. You don't get a more sequre system by making it hard to use.

> The dialogue should be designed carefully and maybe even safety mechanisms
> should be added, like a panic button for people who didn't know the file was
> executable and a notable alert should be displayed when NicePictures.jpg
> suddenly appears to be executable.

True. The user should be displayed a popup telling them this is an executable that may "harm you computer", and ask if it's okay to run it. Absolutely.

Current checkbox "Allow executing file as program" doesn't even tell the user it can be unsafe to run downloaded executables, so this new popup is even more secure than current workflow!

(In reply to comment #2)
> Four years later and nothing has happened. Where can I find the sources
> responsible for this insane behavior?

"insane behavior"? How come? Unix (and therefore GNU/Linux) has the executable bit for *decades*, and you're asking Nautilus an "easy" way to execute a file that is *not* marked as executable? That is *nonsense*!

Also nonsense to say that this 30+ years old "policy" is "hindering normal workflow". Normal to who? In GNU/Linux the "normal workflow" to easily install software is to *use your package manager*. The normal worflow is to get a properly packaged software, be it a .deb, .rpm, or a compressed tarball.

Downloading a ".bin" file from a random website is the *Windows* workflow, not the Unix one. So why should Nautilus suggest a foreign (and insecure) workflow?

Also, to which files you suggest Nautilus to present such message? .bin? Why .bin? .bin for me is a binary image, for example a CD-ROM rip. Not all .bin are meant to be executed. So why would anyone execute a file that should be burn (or mounted)? What is the criteria to know that a file is meant to be executed? (answer: executable bit!)

Even Windows is moving in the opposite suggestion of what you are suggesting: downloaded executables are flagged as being foreign and therefore it does NOT execute it when double-clicked. So Windows makes it harder and Nautilus should make it easier?

Every system is "hard to use" when you completely disregard a system's normal workflow and try to enforce a foreign one.

Mr. Silva please read my answer to the similar trolling you did to my original bug report: Bug 697737.

As you will find in my reply, Nautilus interprets files as executable by it's header. Not it's executable bit or it's file extension.

If you right click an executable in Nautilus and look under Basic you will se "Type: executable (application/x-executable)" even though the executable bit has not been set and even though there is no file extension.

Also you can see that Nautilus displays an executable icon to the file even though no execution bit is set.

readelf -h displays:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - GNU
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x432380
  Start of program headers:          64 (bytes into file)
  Start of section headers:          20702992 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         10
  Size of section headers:           64 (bytes)
  Number of section headers:         34
  Section header string table index: 31

Even when no executable bit has been set. Notice the very clear "Type:                              EXEC (Executable file)" information.

Also your security concern is bullshit because as I said, the executable bit can be set when not being admin. So it doesn't do anything for security when the user owns the file. Nautilus should pop up a dialog asking if the user want's to run the executable file (and of course - set the executable bit if the user clicks Yes) and run it.

Scenario:

1. User double clicks (or opens) a file that has an ELF header or #!/bin/bash header (or whatever is interpreted as an executable):

if(executable_bit_set)
{
-> run the file straight away as usual
}
else
{
-> pop up a dialog telling the user "this is an executable file, it can be dangerous to run, bla bla bla... Do you want to run it?"

if(answer == YES)
{
-> Nautilus sets the executable bit and runs it
}
}

Setting execute permission to a text file named "script.run" doesn't make it run when I double click it. And it still has the icon of a text file. That's because it doesn't contain an ELF header and is thus not an executable. The execute bit is just a permission, not a classifier. Silva is 100% wrong in all aspects.

Where is the sources for this behavior in Nautilus? I would like to make this enhancement to Nautilus.

(In reply to comment #5)
> Mr. Silva please read my answer to the similar trolling you did to my original
> bug report: Bug 697737.

It was not trolling: the first line was showing how your attitude makes very few people take your (perhaps legitimate) suggestions seriously. 

> Unix identifies files not by extension or by execution bit, but by it's header.
> An shell script is made executable by it's #!/bin/bash header.

That is wrong, that is not how it works. Unix, or more precisely the Linux kernel, only executes files that have their executable bit set. The header, either the ELF (for binary) or "#!" shebang (for text, where "/bin/bash" is just an example, as it can be any executable), is *how* the kernel will execute it. But a shebang alone will NOT make a script executable. And the kernel will only *read* headers for executing a file *if* it has the execution bit set.

That is the how the kernel works, and this is very unlikely to change, because it follows the unix spec that has been so for decades. To bypass the execution bit would have huge consequences.

But, on the Desktop Environment side of things, I agree something can be done to improve user experience. Nautilus could set the execution bit under some circumstances. Let's see if you understand how Nautilus works:

> As you will find in my reply, Nautilus interprets files as executable by it's
> header. Not it's executable bit or it's file extension.
 
Wrong again. Nautilus see a file as executable if it has the executable bit set, not header. Additionally, for identifying file types, for example to know which executable must be executed to open a given file, it follows the MIME Spec as defined by freedesktop.org. 

And the MIME Spec uses *both* extension (globs) and "header" (magic numbers) to identify a file. Create a 0-byte file called "myfile.png" and it will identify the file as a PNG image, even if there's no header.

> If you right click an executable in Nautilus and look under Basic you will se
> "Type: executable (application/x-executable)" even though the executable bit
> has not been set and even though there is no file extension.
> Also you can see that Nautilus displays an executable icon to the file even
> though no execution bit is set.

You are deeply misunderstanding the concepts: a MIME type of a file has *nothing* to with its (kernel) execution mechanism. It is merely a way to know, for example, which icon to display or which application to launch to read that file. The Mime database is what allows you to associate applications with (data) files. It does not deal with execution. And for a good reason: it is not a reliable way to detect if a file should be executed or not.

Concepts understood, let's take a look at your suggestion:

(In reply to comment #6)
> Scenario:
> 
> 1. User double clicks (or opens) a file that has an ELF header or #!/bin/bash
> header (or whatever is interpreted as an executable):

The tricky part is the "whatever is interpreted as an executable". *HOW* to interpret a file as executable? By their *mime type* ??? If they are "application/x-executable"?

Ok, nice. But problem is: this covers only a small group of executables. Try to see the mime type of GoogleEarthLinux.bin, which motivated the bug report. Is it "application/x-executable"? NO! It is "application/octet-stream".

So your suggestion would NOT solve the reporter's problem.

Or try it with ".run" files, another good example of commonly downloaded "executables". For example, "amd-driver-installer-catalyst-13.1-linux-x86.x86_64.run", which is AMD/ATI proprietary video driver installer. Is it "application/x-executable"? NO! "application/octet-stream"? NO! It is "application/x-shellscript". 

So now what? Should Nautilus "interpret as executable" every "application/octet-stream" or "application/x-shellscript" too? And also Python scripts perhaps? 

That would "execute" .bin images that are not ELF files, scripts that are meant to be *sourced* (rather than executed), and Python modules that are meant to be *imported*.

How to solve this problem?

Using 'readelf'? But...

(A): that would override the Mime Standard detection, where a file could change its mime type depending on file extension. Get an ELF and change extension from nothing to .bin to .iso. 'readelf' report is the same, mime type is not. So are you suggesting to go beyond Mime Spec? Extend/Override/Ignore it? How would that "new spec" work?

(B) That's only for ELF files. What about '.run', '.sh' and '.py' scripts? How to know  which should or should not be executed?

So, you see, there is no trivial solution to this problem. The adopted solution is to run only files marked as executable by their executable bit. The file's mime type or header or extension or content has NOT enough information for Nautilus to decide otherwise.

> So stop being a fucking dick about it and think outside the box to make a
> better system. A system that does not obstruct the users from their goals.

Apart from the offensive language, which undermines any serious discussion, the solution you proposed is not feasible. Not because of security concerns (they are true, but it's not the major point here), but simply because "whatever is interpreted as an executable" is too vague and there is no current way of reliably interpret a file as executable if not by using the executable bit.

You can propose one to make a better system, but to "think outside the box" you first must understand how the box currently works.

Something your statements show you clearly don't.

Please be aware that people do actually read these bugreports. So a discussion is ok, but please keep it polite.

It is important to understand the difference between different abstraction layers of this issue.

Silvio is obviously only talking about the underlying technical back-end to this issue, while I'm mailny focused on the top level (GUI-layer) of this issue.

All I'm saying is that whenever (however, technically) Nautilus knows (through some kind of heuristics, like ELF header for instance, or MIME of some kind) that the file being open IS an "executable" it should display some kind of pop-up.

Messages from Nautilus like (exact quote from version 3.6):

> Could not display “qt-linux-opensource-5.0.2-x86_64-offline.run”.
>
> There is no application installed for “executable” files.
> Do you want to search for an application to open this file?
>
> Yes | No

Is really not that great. I would call these messages "idiotic", but then I'm suddenly a "newbie that don't know anything other than Windows OS". Okay, so enough with the personal attacks.

I would rather see a pop-up here, telling me "Hey, this looks like an executable, would you like to give it the permission to run?".

I'm not that interested in the underlying technical back-end of the detection of executables, and Silvio might be correct that it can be hard to find a one solution for every type of file, but at least ELF-fiels should be correctly identified I think - but then again, I don't care that much for the underlying technical bit (as this bit can be improved through revisions of the code). I just want a better GUI.

Do a string match or whatever (I'm kidding...), messages like "There is no application installed for “executable” files" is kind of Catch 22 for new users.

Peace.

Silva*

(In reply to comment #10)
> All I'm saying is that whenever (however, technically) Nautilus knows (through
> some kind of heuristics, like ELF header for instance, or MIME of some kind)
> that the file being open IS an "executable" it should display some kind of
> pop-up.

Currently there is no such heuristics. The only way Nautilus knows that a file is an executable is if it has the execution bit. Because in Linux that's what an executable *is*, despite any header or mime type.

> I'm not that interested in the underlying technical back-end of the detection
> of executables, and Silvio might be correct that it can be hard to find a one
> solution for every type of file, but at least ELF-fiels should be correctly
> identified I think - but then again, I don't care that much for the underlying
> technical bit (as this bit can be improved through revisions of the code). I
> just want a better GUI.

But to make a better GUI one *must* understand the underlying technical back-end of the detection of executables. If you want Nautilus to have some kind of detection, then specifics are needed. "whenever, some kind, like" does not help.

And detection of ELF headers is not enough: it does not cover a big part of "executables" and installers downloaded from the internet, like the so common ".run" files, shell scripts and so on.

Actually, I suspect very *few* of the installers out there are pre-compiled ELF binaries. Since the Linux traditional way is to distribute use either source (via .tar.gz tarballs) or packages (.deb, .rpm, etc), most installers that does not follow this route are foreign software, and are either "bootstrap shell script + embedded blob", like ".run" files, or wrappers around wine  (like Picasa or TeamViewer). And these do NOT have an ELF header.

And for Nautilus to suggest execution of shell scripts that are not marked as executables opens a dangerous can of worms.

And I'm not even sure *if* Nautilus should suggest that, even if it was feasible to find a consistent, reliable way to detect "executables". As you said before, any user can google and in 10 minutes he/she will learn what is an executable in Linux. And hopefully after such research will be able a much more conscious, educated decision of whether to mark or not files as executables.  

Naulilus, just like Windows Explorer, only executes by double-clicking files that are executables. Any other file it tries to open an associated application. And the concept of what an executable is in Linux is different than Windows. Regardless if the mime type of a file is "application/x-executable", an executable is a file with the execution bit ON. IMHO, conveying that concept is more important than trying to bypass it.

I understand what you are saying but there is one thing that I cannot swallow:

You keep saying that "The only way Nautilus knows that a file
is an executable is if it has the execution bit.". This, is not true. It's not. I have tested it, I have seen it, it's not true.

Execute permission does not make an executable. Maybe in "pure Unix world", but it's not true in GNOME.

I can (and have tested) setting execute permission on many files that are not ELF binaries (or scripts), and they are NOT made runnable. Execute permission does not mark the file executable (again: maybe Unix says this is how it should be, but it's not how it works in GNOME 3.6).

I'm only talking from GNOME experience, I have used GNOME as my only OS since 3.0 and I'm quite sure I know what I'm talking about here.

Proof:

* Set execute permission on a JPEG. Still an image. Remove .jpg extension. Still an image. Conclusion: some kind of header heuristics are used.

* Create a text file, "script.run". Set execution permission. Still opens in gedit. Still text icon. Remove .run extension. Still text file. Conclusion: some kind of header heuristics are used.

* Open an ELF binary not having the execute permission. Nautilus tells me it's an executable, but wont run it. Set execute bit. It runs. Conclusion: some kind of header heuristics are used.

I can go on and on and on. I simply cannot map your lectures on Unix, to reality. Reality is not what you say it is. This is how it works in GNOME. I want to make it better.

Peace.

file -i <file> determines ELF binaries as "application/x-executable" even though the executable permission is not set.

I really do not see the problem here?

GET_MIME;
IF MIME == "application/x-executable" THEN
SHOW_POPUP;
IF ANSWER == YES THEN
SET_EXECUTE_PERMISSON
RUN
ENDIF
ENDIF

"application/x-executable" can be stored in a vector of strings known to be executables.

Solved. Let me see the sources so I can add this popup. Where should I look?

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

What's the state of this bug? 5 years later there is no progress. AppImage users request some better treatment of ELF executables in GNOME regularly. It would be great to see GNOME implementing some "Do you want to make this application executable?" dialog for ELF files.

See https://bugzilla.gnome.org/show_bug.cgi?id=794578 for further details on this use case.

We are planning to disable random binary file execution in Nautilus for the next release 3.30. Apps should be handled by the application center, rpm or deb files already have proper integration on are handled there, other formats can follow. 

In the use case of developers running scripts, they are better run from the terminal, since from Nautilus they don't show any feedback.

On top of that we had CVE's in Nautilus due to this (it was desktop files though), which we are not experts in fixing.

Follow the disabling of binaries running is tracked in GitLab now at https://gitlab.gnome.org/GNOME/nautilus/issues/184

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.