Trying to run an appimage from my terminal i get :


I found a suggestion to use the '--no-sandbox' which works.

I dont have a clue what the error is happening but i guess that sandbox is related to security. So i am worried. Is it safe to run an appimage with the
'--no-sandbox' option?
And if it matters a lot how can i correct that error?

The error message above that you're getting means that the file mentioned above needs the SUID bit set on it, and needs read, write and execute permissions for the owning user, being the root user in this case, and read and execute permissions set for the owning group and everybody else (otherwise known as "world").

A "sandbox" is basically a tightly controlled environment so whatever is running within a "sandbox" should not be able to harm the host system.

Apart from the solution you've already mentioned (the --no-sandbox argument), you can try the following:

My concern is not only in running the app i want but to run it in a way that is secure.

Reading a 7 years old thread on the same subject i am concerned.
https://forum.unity.com/threads/why-...id-set.365818/

I repaet that i know nothing on chroot and sandboxing tech but to be given the option to give root privilages to a third party sandbox mechanism
or run my app without sandboxing doesnt look reassuring .
In the contrary they way the choice is presented is alarming to me.

Did you build this appimage? If not then did a trusted source build it?

No , i didnt build it!..

I am alarmed because i read about security issues and i have the feeling that we are in a scam wave that is reinforced by the cryptofrenzie.


I am not feeling easy with a system that has as a base a stable debian bun on top of it i have 10-20 appimages or flatpacks , steam , gog installers , itch.io etc .. (not to mention that firefox scares me when once in a while it startsh eating my ram) ..and you got the point. In security terms i think that such a system has an attack surface getting larger and larger...

So i try to find a way to run off-repo apps in a more secure way. Sorry if i was misunderstood initially.

In that spirit i keep finding posts on internet that appimages that intergrate electron framework have the same issue in debian.

For example: lossless-cut
where is suggested :
a note taking appimage 'joplin'

a messanging appimage 'patchwork' ,

and a game appimage 'Thrive'
In that discussion is interesting that althouth chrome-sandbox comes with chrome the game in order to avoid dependencies and be self contained it offers its own chrome-sandbox , so we get to an interesting? situation of a game wanting root ?


Also here is the related discussion in the electon github page.
Electron has chromium as a basic part of its package.


And regarding the option to run the appimage after configuring the kernel with
that worked!.. There are opinions that by doing that you soften the debian patched kernel but is seems preferable to gaving root permissions to chrome-sandbox. Althought i dont understand how can avoid that after having set a kernel parameter..
What does enabling kernel.unprivileged_userns_clone do?
And another related discussion.



So what processes must be owned by root?
What if another app package asks the same for another
program? Is that an issue of a postinstallation script
forgetting to set a permission so we should report an issue to the
distro bugtracker or we have a certain jail tech that want tobe root but that practice is not necessarily endorsed by the distro policies?

Is this the program that some appimages need ?:
$ apt-file search chrome-sandbox
chromium-sandbox: /usr/lib/chromium/chrome-sandbox

Mmm.. i think (from what i read) that to sumit up :
A certain appimage wants to run in a sandbox . Two alternatives are:
The namespace sandbox ($ sudo sysctl kernel.unprivileged_userns_clone=1)
the setuid sandbox. (that it seems its depracated??)

But i'd be great to have a more experieced opinion on that.

The problem you have is that; you can't change/set permissions on a file that doesn't yet exist, but by the time said file does exist it's too late. So you're in a catch 22 situation there.

That's the problem with Appimage's, snaps, and similar - the program said Appimage is for, along with the supporting libraries are embedded within the executable (the Appimage file), so you can't set permissions, or change configuration on files embedded within the Appimage itself - this is why I'm not a fan of them myself and prefer the "traditional approach" instead.

While I'm not sure it's worth the time and effort; you could extract the filesystem image from said Appimage, set whatever permissions you need on said files, then build your own Appimage of whatever it is. Again, I'm not sure it's worth the time and effort, but that's one option if you are that concerned about security. Another option is to run the Appimage within a virtual machine, which would be a much easier option.

In any case, if you wish to build your own Appimage instead, then the following links might help you. You can use "appimagetool", have a look under the heading "AppDirs and AppImageTool" in the first link below:
https://www.booleanworld.com/creatin...here-appimage/
https://superuser.com/questions/1301...om-an-appimage

1 members found this post helpful.