-
Notifications
You must be signed in to change notification settings - Fork 23
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
chmod chrome-sandbox: operation not permitted #62
Comments
Hey @northys, thanks for the report. This is a fix for electron on older kernels that don't support unprivileged USERNS_CLONE. You can find the details here: This shouldn't fail though, but more, this shouldn't be executed as your kernel should have support for unprivileged USERNS_CLONE. |
Hi @northys, could you share the output of |
» sysctl kernel.unprivileged_userns_clone
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory
northys at northys-fedora in ~ » sudo sysctl kernel.unprivileged_userns_clone
[sudo] password for northys:
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory
…On Jan 25, 2022, 09:13 +0100, Patrick Pacher ***@***.***>, wrote:
Hi @northys, could you share the output of sysctl kernel.unprivileged_userns_clone ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Thanks for the output. Seems like there's no such file on your system. I just downloaded and installed a fedora locally to test that and I'm able to reproduce the issue. I will ping you once we have a proper patch available (we changed some stuff in the beta release channel but I fear that fix is incomplete). |
So it turns out there just no easy way to reliably detect whether or not unprivileged user namespaces are enabled or not. Right now I see the following possibilities:
To sum up, I'm not sure trying to correctly detect that is worth the effort. Maybe we can just set the SUID bit by default on chrome-sandbox and provide a flag to disable that behavior in case somebody really want's to avoid having an SUID binary lying around. That would be the best choice for user experience. Security wise, we could NOT set the SUID bit and rather try to inform the user that this needs to be done manually after an upgrade of electron. Though, communicating this is hard since the UI doesn't start and it might be hard to fix for less tech-savvy users. My pitch would be to set the SUID bit and let users disable the behavior using a |
Sorry for late reply I forgot about this issue. I actually don't understand the internals much and the log isn't bothering me since everything works. I just wanted to ask if everything is fine and whether I should care about the warning. So it's up to you to figure out how to solve this issue. Someone would say to write it to doc but who reads the doc right? :D |
What happened:
I just noticed a warning about chmod failing for chrome-sadnbox while digging into different issue. I'm not sure if it is a problem actually. It's happening since 14. November. All paths I got by grepping logs start with
/opt/safing
so I suppose that started after me switching from manuall installation to fedora package.What did you expect to happen?:
How did you reproduce it?:
Debug Information:
Version 0.7.11
Platform: fedora 35
Status: Trusted
Resolvers: 5/5
No Module Error
Unexpected Logs
Goroutine Stack
The text was updated successfully, but these errors were encountered: