! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
add a way to *open* shell scripts instead of executing them
Status:
RESOLVED: FIXED

Comments

Description Yves-Alexis Perez editbugs 2011-05-09 17:55:59 CEST
Hey,

currently, Thunar detects shell scripts and presents an interface enabling to change the permissions (in the file properties). When the file is executable (+x) double clicking on the scripts runs it, while when it's not, double-clicking on it opens it in an editor.

I have some users requesting a way to always have them opened in an editor, even when they are executables: basically they don't execute it from Thunar, and want to be able to browse them / edit them.

Downstream bug is at http://bugs.debian.org/575385
Comment 1 bugzilla.5.kyoo 2011-06-03 05:04:12 CEST
It looks like you can right-click an executable file and choose a program from the Open With menu.  I'm using Thunar 1.2.1.
Comment 2 Yves-Alexis Perez editbugs 2011-06-03 07:59:34 CEST
(In reply to comment #1)
> It looks like you can right-click an executable file and choose a program from
> the Open With menu.  I'm using Thunar 1.2.1.

This is about the double click.
Comment 3 Nicklas Bo Jensen 2012-05-25 11:38:15 CEST
I second this feature request. 

You could do it similarly to what Nautilus does, where double clicking an executable shell script gives a popup asking if it should be displayed or executed.
Comment 4 Jeez, Don't Make Me Naked 2014-01-25 18:17:22 CET
I would like to throw my voice onto the pile.  This shortcoming opens the user up to unnecessary risk.  Both Nautilus and Caja provide options for editing, executing, or confirming upon activating a script file--but alas, fair Thunar.  My eyes can see no other.

The problem is being discussed on the Xfce forums:
http://forum.xfce.org/viewtopic.php?id=7407

... and has been marked as a bug in Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575385
Comment 5 Xen2050 2014-02-04 02:47:07 CET
Created attachment 5349 
Patch for Thunar 1.6.3 to treat shellscript files like any regular file, do NOT execute, instead use "Open With" menu.

I've attached a patch to treat shellscript files like any regular file, do NOT execute, instead use "Open With" menu where you can change the default application, use Text Editor, Terminal Emulator, etc.

I edited the function thunar_file_is_executable in thunar/thunar-file.c that decides which files are executable or not by checking the mimetype. Before, if a file's type is "application/x-executable" OR "application/x-shellscript" then it would execute, causing the bad behaviour with scripts running "invisibly" in the background, and for whatever reason you can't add or change a default "open with" application for executables.

I first tried changing thunar_file_is_executable to only say "application/x-executable" files are executable but it didn't seem to work, for whatever other reasons "application/x-shellscripts" were still coming back as executable (maybe x-shellscript is a subset of x-executable? Something to do with g_content_type_is_a ?).

But changing it to first check if a file's an "application/x-shellscript" and if yes then don't say it's executable does work!

It may even be better than the Nautilus/Caja pop-up menu since now with Thunar you can always use the default application on double-click with no pop-up menu in the way.

I tested it on Linux Mint 16 XFCE x86_64 (Ubuntu based) and I used the 4f10d5d5576ce5127308d6badbac3afa 1983127 thunar_1.6.3.orig.tar.bz2 source code file. The Ubuntu(?) file thunar_1.6.3-1ubuntu1.debian.tar.gz doesn't appear to change thunar/thunar-file.c, so I think this would be good for any non-Ubuntu build too.
Comment 6 MRule7404 2014-06-17 23:32:46 CEST
Hi, I created an account specifically to add support for this feature. Since Thunar does not indicate which files might be executable, it is too easy to accidentally execute a script when attempting to open it in the editor. 

Additionally, there is no "run in terminal" option to view and interact with executable scripts while running. I would strongly support temporarily disabling the run-on-click feature ( and perhaps moving it to the dropdown menu? ). 

Something akin to nautilus' confirmation dialog ("edit" "run" "run in terminal") would be welcome.
Comment 7 Richard Baxter 2014-07-09 04:42:55 CEST
This is a critical issue - it is both dangerous and inconvenient for a Linux file manager to be executing scripts in the background when they are attempted to be opened; at the very least a warning box should appear. 

A more robust, simple, and efficient implementation for a graphical file manager on Linux would use file extensions rather than mime headers to associate actions/applications. This prevents anomalies like .bat, .dat, and .txt files all being designated "Plain text document" and being mixed together when a folder is sorted by "type". Applications and scripts should be launched via the window manager start menu or terminal command.
Comment 8 Olivier Delrieu 2014-08-04 04:20:12 CEST
I've just created a bugzilla account here to second this feature request.

I believe accidental script execution is a major issue. 

IMHO, the user should have at least the option to choose the behavior of double clicks for executable files: execute / ask (default) / edit
Comment 9 Aaron B 2014-09-30 21:54:45 CEST
New user of Xfce (Xubuntu) here, loving it, great job team!
Also joined just to request this feature. The 3 options as Olivier described would be ideal.

This is definately a security issue (can we tag it as such?), as it makes it much easier for a user to be tricked into executing malware, due to a shell script's similarity to a regular text file.
Comment 10 Olivier Delrieu 2014-10-21 17:34:37 CEST
This thread is 3+ years old. I'm wondering if we shouldn't open a new bug report to get some attention. Thoughts?
Comment 11 Aaron B 2014-10-21 22:21:55 CEST
I'm not sure what usual protocol is, if that's the case then sure we can open a new one.
In my opinion its better to keep the same bug and try contacting some people.

Can someone change the status of the bug to CONFIRMED? I don't seem to have privilege to do so. Is there a way we can mark it as  asecurity issue as well?
Comment 12 Nick 2014-11-18 21:37:56 CET
Olivier's proposal sounds very nice.

This issue isn't limited to shellscripts--it affects all plaintext scripts set as executable, regardless of language--and seems like a serious security shortcoming.
Comment 13 orestisf 2014-12-26 17:00:05 CET
just made an account here to second this proposal. This is both annoying and dangerous!
Comment 14 Steve Dodier-Lazaro editbugs 2015-02-15 04:39:20 CET
I'm making this report a duplicate of https://bugzilla.xfce.org/show_bug.cgi?id=9934 since 9934 has more elaborate discussions on the security and usability aspects of the default we want to enact.

It also has a precise list of steps to be taken for both issues to be solved. Please comment or contribute there!

Thanks.

*** This bug has been marked as a duplicate of bug 9934 ***
Comment 15 Harald Judt editbugs 2015-02-19 13:00:45 CET
This patch will be applied for the next release if no one objects. While considerations are similar for the other (duplicate) bug #9934, I am removing the duplicate attribute because shellscripts are usually executed on the shell. They often need parameters or they will not work. I also agree with the security issues raised, and personally I would not want to execute a shellscript with thunar, but rather have it opened (by default).

It would be nice of course to have an easy way to "Run in terminal" from the context menu. At the moment, though, the user can use a custom action for this.

Thanks to Xen2050 for the patch.
Comment 16 Harald Judt editbugs 2015-02-19 23:40:13 CET
Pushed a modified version in http://git.xfce.org/xfce/thunar/commit/?id=ed2274884c25e4e689982c7756d21b5c230d03bc.
Comment 17 Harald Judt editbugs 2015-02-28 13:41:44 CET
Improved behaviour in http://git.xfce.org/xfce/thunar/commit/?id=b385bcf7c856fdc0a63b5f91a6d4053a7d22347e. Works with all shell script types now and has a hidden option to restore the previous behaviour. More future work is needed here, but for the moment that's it.

Bug #7596

Reported by:
Yves-Alexis Perez
Reported on: 2011-05-09
Last modified on: 2015-02-28

People

Assignee:
Jannis Pohlmann
CC List:
12 users

Version

Attachments

Additional information