please allow to configure execute permissions and other default settings

[edmundlaugasson]

Is your feature request related to a problem? Please describe.

Possible security issue in case of certain circumstances. Currently AppImage Launcher gives execute permission to all users by default, not only owner as it suppose to be. In addition - this is not configurable currently.

Sometimes there could be also other permissions needed. This means, that default permissions given by AppImage Launcher, needs to be changed for time to time.

Describe the solution you'd like Something like this: These would be default permissions, that will be applied when running *.AppImage file via AppImage Launcher. Changes will be saved but dialog window will be still open when using Apply button. When using OK button, changes will be saved and dialog window will be closed.

When changing any value after opening the settings dialog, the changed value will be emphasized via star in the beginning of row - like in Midnight Commander, which I used as an example with some additions. Then it is clearly seen, which values have been changed since opening the AppImage Launcher Settings.

Also permissions octal value will be changed in real-time according changed permissions - just like in Midnight Commander.

One more idea: Owner and Group could be drop-down menu also to change these values. Again - changed value has a star in the beginning of field to determine changed value since last app start.

Certainly there will be a check whether current user has permissions to change these values for chosen file and if no permissions, then there should be appropriate error message saying so. There could be also then a small button to launch AppImage Launcher as appropriate user with proper permissions (can be chosen also manually) in order to be able to change permissions and ownership.

There could be also other settings under that dialog in future, not only permissions and ownership.

Describe alternatives you've considered Currently manually via CLI (also using Midnight Commander) or GUI these values can be changed.

Additional context Quite often people forgot to fix permissions and then too dangerous permissions are given for users, who do not need these. It is very much depending on the current AppImage file, but as we know, these can be very different ones. Also user homes are not with permission 700 but usually 755 - so every user in system can access these AppImage files. When there are execute permission to everyone, then also users not eligible, can run AppImage apps. Imagine, that there can be apps, that may contain sensitive information (e.g. credentials storage) or can be used in any other inappropriate way, depending on the app. So, security by obscurity is a very bad idea. Therefore I propose such improvement to give only necessary permissions and give full control to user over permissions. Certainly creating user home with permission 700 would be good thing to fix, but not all Linux distribution makers nor sysadmins will not do that. To avoid accidental leakage, allowing to configure default permissions, ownership would be a good option.

[TheAssassin]

First of all, you have some misconceptions, so I doubt you have read the code, but made guesses on the behavior. AppImageLauncher does not enforce permissions like you suggest. It just adds the executable bits on top of the existing permissions.

https://github.com/TheAssassin/AppImageLauncher/blob/3f901f6419d9ba5bee15bc101d4b9b0adb5e343e/src/shared/shared.cpp#L70

Possible security issue

I don't see any security issues, honestly. You are making a point about file permissions, but I cannot think of an attack vector created by making the files executable by everyone.

AppImages are usually not confidential, and even if they were, we don't touch the read bit. Browsers for instance follow the umask, which, on most systems, is 0002 or 0022 (i.e., files are created with at least readability for everyone, and on some Ubuntus the group write bit is also set).

Way more than 90% of all AppImages ship free software. Nothing prevents another user from downloading the file as well.

Given that the files are in your home directory, I'd be more concerned about your home directory being world readable. Making your home directory 07x0 already mitigates the issue. If it's 0755 for example, any user can read all the files anyway. They can then also just copy the binary, make it executable in some other place (e.g., /tmp).

The only scenario in which an issue could be created is when AppImages on the system have permissions like 0xx1. In that case, any user can execute the file, although they cannot read it (directly). However, again, that would only really be an issue if:

1. your home directory is accessible by any user
2. your Applications directory is accessible by any user
3. the AppImage is in some way confidential and cannot be downloaded other wise

The chance for such a scenario is really, really, really low. It's not impossible, but really is not a standard setup.

I think it is fair to make a decision here and add hardcode those bits we add. If anything, we change the default behavior. However, I still don't see any advantage in not adding the executable bit for everyone.

An alternative is to just read the umask and depending on it set the executable bits. So, depending on whether (new) files are supposed to be world/group readable, we also set the executable permissions accordingly.

Examples:

• umask 0022 -> owner, group and world executable
• umask 0002 -> owner, group and world executable
• umask 0027 -> owner and group executable

As said before, a totally suitable mitigation to the issue (if you consider this an issue at the moment) is to just shut off access to the Applications directory.

but not all Linux distribution makers nor sysadmins will not do that

Can't fix the world. If your default setup is like that, the average user is not "protected" (really the wrong term) anyway.

allowing to configure default permissions, ownership would be a good option.

I really do not want to interfere with default read/write permissions. There is an established, well working mechanism around called umask. Using the umask to deduct our own behavior is totally adequate.

Something like this:

The dialog you suggested is unnecessarily complex.

If there would be any configuration options for this, we'd only ever worry about the executable bit anyway. And that could be covered in a single dropdown. I think of a dropdown like "auto-detect using umask", "owner", "owner and group" and "owner, group and all users" or something like that. But the first thing to do is to implement some auto-detection. Average linux users won't ever open that settings dialog.

PRs welcome, by the way.

[edmundlaugasson]

OK, then it is umask issue, certainly. Although it could be an option to "fix the world" by adding such tab and overriding default umask. Only attack vector is leaking sensitive data via allowing non-owners to run certain apps, e.g. credentials storing apps, etc. As long as home folder is not writable others than owner, everything should be fine.

[TheAssassin]

Only attack vector is leaking sensitive data via allowing non-owners to run certain apps, e.g. credentials storing apps.

This is not really an attack vector opened by the fact that we make AppImages executable. As long as the home directory is readable and the credentials are stored in a non-encrypted way, these credentials can be read.

If an arbitrary user runs an AppImage, it does not run as the user that owns the AppImage. That would be suid, but that's not set by us.

[edmundlaugasson]

That's true - suid hopefully not happens. Anyway, this was my idea. I see, that not good one.