Execute a download
By Andrew Smith
Some Windows and Mac users will be surprised at this, some will laugh – and well they should. On Linux it’s not possible to just download a program and run it, not even if it’s a program for the right platform. How stupid is that?
The problem is that (probably for no-longer-relevant security reasons) any file you download using a web browser (over HTTP or FTP) will have read and write permissions for the user, and read (or nothing) for group and others – in other words -rw-r–r–, or 644. A double-click on the file in a file manager (or on the desktop) will get the system to think that it’s a data file that needs to be opened in another program, and usually a dialog will come up asking you what program you want to open this file (program) in. Arrrgh!
I’m asking around for a solution, but I suspect there is none. If that’s the case maybe I’ll try to fix it myself – the solution is a couple of lines in C.
Some background: it is possible to have a shell script (let’s call it program.sh) that has more than just shell commands. For example the Loki games installer is a shell script but it has a GUI and a few hundred binary files (possibly in an archive), all this in program.sh. There are other examples of this.
So let’s say we make a new file extension – .esh, for executable .sh, and these will actually be shell scripts, following all the rules of sh/bash. When one double-clicks on such a file in a file manager, the file manager will either:
- Execute the file if it has +x permissions, in which case it will act like a shell script, or
- Treat the file as a data file and will open it in the associated program – this will be my program which I will call esh
The program will be something like this:
/* esh.c */
int main(int argc,char** argv)
{
if(argc != 2) return -1;
exec("/bin/bash", "bash", argv[1], NULL);
}
/* thank you WordPress for deleting spaces at the beginning of a line. grrr */
So if the file manager runs ‘esh program.esh’ it will just execute /bin/bash program.esh, which is exactly what I want – it will give the illusion of a file being executed even if it doesn’t have execute permissions.
Of course then there is the matter of getting distributions to ship with esh installed by default – but maybe I’m not the only one who thinks this is a major misfeature in Linux, and it will get done quickly.
If I don’t find a different solution in a couple of weeks, I will probably go ahead and start pimping this one.
October 5th, 2007 at 8:48
What are the security ramifications of this?
October 5th, 2007 at 9:05
Some argue that allowing users to execute freshly-downloaded file is just asking for trouble, in case it’s a script labled ‘critical update’ that has ‘rm -rf ~’ in it. But I think if someone wanted to do that, there are many other ways to get a virus to run.
An interesting idea I got from a response to this post is to have esh present a dialog to the user asking if they’re sure they want to execute this program, it can have a virus, whatever. I think that’s worth considering.
October 5th, 2007 at 9:05
Please *do not* make things click-and-run on Linux! That’s historically been the introduction point for many trojans/viruses/malware programs.
Most Linux distros already know how to handle packages in their native format (.rpm, .deb, whatever), and bring up a GUI installation tool when those types of files are encountered. But the GUI installers do additional checks: you need a password to run them (either yours or the root password, depending on the distro), and digital signatures are verified to determine the source of the software and whether it’s on your own list of approved sources. I’ve been virus/malware free for years on my Linux network at home; I’d hate to see that collapse if my daughters could click-and-run software.
October 5th, 2007 at 9:08
Yes but can’t your daughters open a .rpm file and do as much damage anyway?
I don’t buy the virus argument, Macs have click-and-run and they’re not plagued by viruses.
October 5th, 2007 at 19:39
My daughters don’t have the root password :-)
You’d have me sold on this idea if the execution environment was well-sandboxed…
October 5th, 2007 at 20:35
Ok then, here’s a different way to look at it: they can already open a terminal and type in ‘sh downloaded.sh’. That will have the same effect as running esh (esh would not require any password). The only difference is that with esh you don’t need to use a terminal.
If you think that’s an acceptable compromise – isn’t that arguing against ease of use and for security through obscurity?
Remember as long as the user is allowed to run shell scripts (just about every Linux user can) the user can do any ammount of damage to files they own, and also install and run programs from directories they own (mounting /home without exec permissions doesn’t help). Anything other than a root-owned whitelist of runnable programs (that cannot include interpreters such as bash, perl, python) is just obscuring the problem. I strongly believe the obscurity will be worked around as soon as it’s cost-efective for someone to write malware for Linux.
This feedback is great. It gives me material for an FAQ that I can have ready when making the proposal to the distros :)
January 9th, 2008 at 13:19
Actually, you can set the defaults on file creation in the profile to make the files you create with the permissions *you* want. If you want to create files with a 755, you can.