A discussion on the "chmod +x"

With just a claim and no information - I don’t see why zipping is a bad idea. It preserves the executable bit and less convoluted to tell someone to unzip a file rather than go dig deep in file properties. File archivers job is to intuitively let people archive/extract and I don’t see it as an issue to leave it up to them.

Agree this should apply to any ELF binaries and not just Appimage.

1 Like

People need to understand that the executable bit (a) is there, and (b) is a security feature. Any method of bypassing the need for the user to give explicit permission should be seen as extremely bad practise.

Imagine downloading a zip archive that contains image.png, which is actually an executable in disguise. You double-click the image to view it and instead the executable runs and deletes everything in your home directory. The fact that (some) archive formats preserve the execute permission is arguably a security flaw, and one that AppImages should not seek to exploit.

All that really needs to happen is someone writes a patch for nautilus (GNOME Files) to give a more helpful message when someone double-clicks on an AppImage (or on any ELF binary) that doesn’t have execute permission. The message could be something like:

Execute this file as a program?

For security reasons, this program currently does not have permission to run on your computer. If you know where it came from and trust the source, click here to grant permission.

A message like this should pop up even if the user is running appimaged, in my opinion. This is equivalent to the warning given on a Mac when the user tries to run an untrusted .app file.

1 Like

Exactly.

Would you be able to write this? I wouldn’t even know where to start.

I approached the Nautilus developers. They were friendly and welcoming, but they said that all platforms (Windows, Mac, Linux) are moving away from allowing untrusted executables to run outside of a sandboxed environment. It is highly likely that quite soon, Nautilus will no longer have the the ability to launch programs by double-clicking on them, even if they DO have execute permission. This means the question of prompting for execute permission is moot, because the program won’t run anyway.

They suggested this course of action:

  1. Add the AppImage MIME-type to the open-with list for a sandbox program.
    • Double-clicking an AppImage runs it inside a sandbox.
  2. Add the AppImage MIME-type to the open-with list for GNOME Software.
    • Double-clicking an AppImage opens GNOME Software and asks if the user wants to install the AppImage.

It may also be possible to modify the spec slightly to make AppImages valid flatpak and/or snap packages, but fully self-contained so that they can still be run independently of those packaging tools.

The bottom line from the lead developer for Nautilus was:

csoriano: [with] respect to the file manager: sandbox with perms framework? ok to run, otherwise, no

Sorry to barge in, but how about making small application that can be registered as handler for AppImage mime type? One that would just display window with big “Run It” button and some sandboxing options.

I’m asking because I’ve drafted something like that and come to check if there is any interest for it, finding this thread as first thing :slight_smile:

scr01

scr02

4 Likes

Registering a handler for the AppImage mime type would technically be an option, but since it would have to be installed on the system, why not let the optional appimaged daemon handle everything automatically. We could integrate a GUI similar to what you are showing there; but even better we would make it “just work” like on the Mac without asking the user questions.

In any case, please avoid the word “install” in conjunction with AppImages, since they don’t need to be installed.

Sorry, I was under impression that is not (currently?) possible. If that’s not the case, I have nothing to offer :slight_smile:

Benefit of using mime type handler would be, that appimaged would no longer need to watch directories. It doesn‘t matter which directory the appimage is saved to.

I think a mime type association with a handler is the better approach, since it relies on basic mechanisms offered by any DE. After all, double clicking a txt or png file is one of the most basic tasks, thus mime handlers can be considered pretty mature.

1 Like

Register a mime could help if appimaged (or another software) is present but it has nothing to do with running the appimage itself.
If there’s a daemon present then register the mime is “free as beer”. If there’s no daemon then it’s a no go way.

I think chmod+x or righ-click->permissions->execute it’s not that hard.
When a user works with linux he needs to know a bit about linux. if I want to drive a truck then doesn’t matter if I’m an ace driving karts… the only thing that really matters is if I know a little about truck driving.
Other thing is that we, as developers, want to give the things the easier possible for the users but hey, if the user don’t know how to make a file executable and don’t want to “learn”… then perhaps he will do better sticking with his os and not blaming linux for be “not as windows/macos”.

Well appimaged (or whatever handler is registered) could then do its magic to chmod-then-launch the file in question. It could even display dialogs such as designed above.

If appimaged is capable of handling the mime type, it would enable distros to behave in a way that the appimage devs want to.

I.e. we don‘t rely on distros to implement appimage specific launcher routines, we „just“ need appimaged to be included in the distribution.

Perhaps I didn’t express myself well, I was talking about the cases when the daemon isn’t available (appimaged package not on distro or not available for some reason…).

I completely agree, and I think this is a necessary improvement over having to use low-level file permissions to mark the .appimage as executable. This is the closest thing currently possible to zipped app bundles on the mac, which I’m amazed that none of the linux environments have copied yet.

The executable bit is a low-level function, meant to separate executables from data files in shell scripts and terminal prompts. It’s not user-friendly enough to pass through to users in a GUI environment.

If the user downloads something with an executable file extension and makes a specific intention to run it by double-clicking, then they are expressing their intent. Ideally the GUI would present a warning and/or authentication prompt the first time an executable is double-clicked before running it. Forcing them to chmod or get deep into a unix-level permissions dialog is a bit cruel.

As it stands, it sounds like a tar.gz file with a shell script launcher is more user friendly than an AppImage, because all the user needs to do is extract the file, then double-click to launch. I think the extraction could even be a bonus, because it gives the user a chance to unpack the app in a location of their choice. The only thing to worry about is the user’s unarchiver stripping the executable bits, but presumably that can be covered by a README file which is referenced only if necessary.

1 Like

I agree - though you can have an AppImage inside .tar.gz just as well, which is what we do. We don’t make use of the AppImage daemon so there’s no downsides to that approach.

1 Like

Your users might be using appimaged…

Almost none aren’t, so it’s a very beneficial approach atm. I’m not getting any negative feedback at all on this from them.

AppImages are twice the fun with appimaged :wink:

I rather have a solution which doesn’t require system wide installation or any privileges.

It should be somehting really simple.
Better even having it as AppImage by itself (In its portable manner with .home and .configure).

What should it do:

  1. Scan user defined directory for AppImage’s.
  2. If there are new AppImages:
    • If the AppImage is marked for execution, integrate it with system menu (.desktop).
    • If the AppImage isn’t marked for execution integrate them with system menu with a .dekstop file which runs it using Sand Box (If available).
  3. If there are missing AppImages, remove their integration.

The above isn’t done using background process. It is a program which does the scan (Once in 5 minutes for that matter) as long as it runs (Let’s say it is a system tray icon). It doesn’t require any privileges or something like that. It is the user responsibility to run it (Or even make it Startup program) at each change of AppImage.

This is a truly AppImage portable inspired integration with the system.

appimaged does not need root rights, does not need to be installed using root rights (it comes as an AppImage itself), and does not need system-wide installation. It does use a background process and inotify which does what you describe, but instantly and without an additional GUI.

I’m new to Linux.
But isn’t a Daemon requires special privileges to run?

Also, how much resources this takes?
Can I configure it to scan single location to reduce its scan time?
Will it automatically run the next time I restart the computer (I don’t want that)?
How can I turn it off once I loaded it?