-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unpriveleged user namespace clone #10
Comments
Hi! Thank you for reach out to us. Looks like it was fixed in the latest electron-builder release. I have published new console release, please check it out, the issue should be fixed: |
Ah OK I see. 0.5.1 appimage still suffers from said electron issue, however appending |
Todo investigate opportunity to enable linux support automatically |
Hi guys,
I'd better write in English just to be clear for those who don't speak Russian, hope you don't mind.
Not sure whether it's a bug or
INTENTIONAL
but...There is an issue with current Minter Console Appimage which is related to security settings used by default in such distros as Arch Linux and its derivatives like Manjaro. I'm talking about
unprivileged_userns_clone
kernel setting which is set to zero by default in order to mitigate potential security issues. The latest Minter Console (v. 0.5.0) requires this setting to be1
to work fine, the previous one (v. 0.4.1) has no problems with the default setting0
.I had a talk on this in @MinterDevChat with someone who assured me there's no such issue on his Fedora installation, I've checked on Ubuntu (it turned out they have
unprivileged_userns_clone
set to1
- don't know how they both mitigate potential risks). openSUSE also has no problem in launching this version of Console (however no idea how it mitigates the risk either). So from what I can see now, Arch-based distros are affected by this.The thing is, there is no valid reason for an appimage to demand me changing my kernel configuration, especially if I am running the stock configuration of my distribution. I believe that there should be no reason to lower the security settings of the kernel as a workaround.
Snap version works fine (probably because of
unprivileged_userns_apparmor_policy
set to1
, but that's OK since snap applications have no access to system's root).The text was updated successfully, but these errors were encountered: