-
Notifications
You must be signed in to change notification settings - Fork 577
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
nvidia driver and noroot setting #841
Comments
I have a fix in 40ed53c I don't have a Nvidia card, but I think it will fix the issue. I added video and games to the groups allowed in the user namespace. I close the bug for now and reopen it if necessary. Thanks. |
I'm seeing this same issue with Firejail 0.9.44.8-1 on Debian with an nVidia NVS 5400M. It looks like 40ed53c either did not fix the issue or it has reappeared. I compiled from the current master (22414ad) and captured the Notably, when running with Thanks, |
I have an Nvidia card and have used |
I can confirm that this is still an issue for me on Debian with firejail 0.9.54-1, nvidia 390.77-1, and Linux 4.18.0 (from kernel.org, without Debian patches). |
That's very interesting. I'm on Debian sid/experimental, with firejail 0.9.55 (from git), nvidia 396.51-1, and Linux 4.17.8 (custom-built from linux-source-4.17). Both |
@kevinoid I'm curious to see if you run into the issue with a Debian stock kernel. Can you test and report back? |
@chiraag-nataraj Sure. I can confirm that the same behavior occurs when running kernel 4.17.0-1-amd64 from the linux-image-4.17.0-1-amd64 package (version 4.17.8-1) with nVidia modules built using nvidia-kernel-dkms (version 390.77-1). |
Damn, that's weird. So I have a newer version of |
Multiple monitors? Different outputs? it has always been arbitrary when the driver calls its suid binary iirc |
I agree. I don't think it is version-specific. I'm currently using the laptop screen. I can test the VGA output soon. If you run Also, for reference, my system has nVidia Optimus, so it has both an Intel graphics card and an nVidia card. The problem does not occur when using Mesa on the Intel card. |
I can confirm the same behavior occurs when using the VGA output with LVDS (the laptop screen) disabled. |
I doubt the output itself would matter, since the same driver would be driving whichever screen(s) you're using.
I actually do see those calls and they do fail with
Yup, I have Optimus as well. |
Is this still an issue? |
Thanks for checking in. I can confirm that this is still an issue for me on Debian with firejail built from the current master branch (feae44c), nvidia 390.116-1, and Linux 5.1.2 (from kernel.org, without Debian patches). |
Hmm, I see. Is this an issue if you use the Debian-supplied kernel instead of the custom build? |
Yep. I can confirm that the same symptoms occur with firejail built from feae44c, nvidia 390.116-1, and Linux 4.19.0-5-amd64 (from the linux-image-4.19.0-5-amd64 Debian package version 4.19.37-3). |
I'm wondering if it just has to do with something they changed on their end, since I'm on 418.74... |
But looking back, that doesn't seem to matter...I'm stumped. |
If you do |
I added the output of |
Hold on. Your |
That is correct. On my system |
That's so odd...I would presume they'd both attempt to access the Nvidia driver the same way... |
For the record: similar thing with With @netblue30 Maybe add a hint regarding |
@czka done. |
@rusty-snake Kewl! |
@rusty-snake Could you close due fixed and no feedback? |
Maybe we want to keep it open until we have a better fix then adding a note that nvidia-users should add |
Temporary fix in for the next release: I disable nogroups if /dev/nvidiactl is detected in the system. If it is working we go with it in the next release and find a better way to do it later. |
Remove workaround from commit 623e682 ("temporary fix for nvidia/nogroups/noroot issue (netblue30#3644, netblue30#841)", 2020-10-02) and from commit cb460c3 ("more nvidia (netblue30#3644)", 2020-10-03). The handling of the "render" and "video" groups is separate from `nogroups` now, so disabling `nogroups` on nvidia shouldn't be necessary anymore. See the previous 2 commits for details. See also the discussion on PR netblue30#4632.
`nogroups` should not have been causing issues with rendering on nvidia since commit 623e682 ("temporary fix for nvidia/nogroups/noroot issue (netblue30#3644, netblue30#841)", 2020-10-02) and commit cb460c3 ("more nvidia (netblue30#3644)", 2020-10-03), which had made it a no-op on nvidia. And the handling of the "render" and "video" groups are independent to the handling of `nogroups` now; see the previous 3 commits. Commits which introduced the comments on each profile: * kodi.profile: commit ce462b6 ("fix netblue30#3501", 2020-07-16) * mpsyt.profile: commit e17b48f ("new profile mpsyt.profile", 2018-11-28) * mpv.profile: commit cc7c489 ("Document netblue30#1945", 2018-07-25) * steam.profile: commit d6f8169 ("steam fixes; netblue30#841, netblue30#3267", 2020-03-15) Commands used to find the comments: git grep -i nvidia -- etc/profile-* | grep -v private-etc Relates to netblue30#4632.
It has been reported in netblue30#6372 that after upgrading the nvidia proprietary driver from version 550.78 to 550.90.07, programs using hardware acceleration fail unless paths in `/sys/module/nvidia*` are accessible. Example: $ firejail --noprofile prime-run /bin/glxdemo [...] X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 150 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 22 Current serial number in output stream: 23 [...] Meanwhile, the AMD proprietary driver (AMDGPU Pro) seems to depend on `/sys/module/amdgpu` for OpenCL (though it is unclear how to detect that driver). See commit 95c8e28 ("Allow accessing /sys/module directory", 2018-05-08) and commit 9dd581d ("Allow AMD GPU usage by Blender", 2018-05-08) from PR netblue30#1932. So whitelist `/sys/module/nvidia*` by default if the nvidia proprietary driver is detected and `no3d` is not used. Note: The driver check is copied from src/firejail/util.c (see netblue30#841). To keep the current behavior (that is, block all modules), add `blacklist /sys/module` to globals.local. Fixes netblue30#6372. Reported-by: @GreatBigWhiteWorld Reported-by: @orzogc Reported-by: @krop Reported-by: @michelesr Suggested-by: @glitsj16
It has been reported in netblue30#6372 that after upgrading the nvidia proprietary driver from version 550.78 to 550.90.07, programs using hardware acceleration fail unless paths in `/sys/module/nvidia*` are accessible. Example: $ firejail --noprofile prime-run /bin/glxdemo [...] X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 150 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 22 Current serial number in output stream: 23 [...] Meanwhile, the AMD proprietary driver (AMDGPU Pro) seems to depend on `/sys/module/amdgpu` for OpenCL (though it is unclear how to detect that driver). See commit 95c8e28 ("Allow accessing /sys/module directory", 2018-05-08) and commit 9dd581d ("Allow AMD GPU usage by Blender", 2018-05-08) from PR netblue30#1932. So whitelist `/sys/module/nvidia*` by default if the nvidia proprietary driver is detected and `no3d` is not used. Note: The driver check is copied from src/firejail/util.c (see netblue30#841). To keep the current behavior (that is, block all modules), add `blacklist /sys/module` to globals.local. Fixes netblue30#6372. Reported-by: @GreatBigWhiteWorld Reported-by: @orzogc Reported-by: @krop Reported-by: @michelesr Suggested-by: @glitsj16 Tested-by: @flyxyz123
It has been reported in #6372 that after upgrading the nvidia proprietary driver from version 550.78 to 550.90.07, programs using hardware acceleration fail unless paths in `/sys/module/nvidia*` are accessible. Example: $ firejail --noprofile prime-run /bin/glxdemo [...] X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 150 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 22 Current serial number in output stream: 23 [...] Meanwhile, the AMD proprietary driver (AMDGPU Pro) seems to depend on `/sys/module/amdgpu` for OpenCL (though it is unclear how to detect that driver). See commit 95c8e28 ("Allow accessing /sys/module directory", 2018-05-08) and commit 9dd581d ("Allow AMD GPU usage by Blender", 2018-05-08) from PR #1932. So whitelist `/sys/module/nvidia*` by default if the nvidia proprietary driver is detected and `no3d` is not used. Note: The driver check is copied from src/firejail/util.c (see #841). To keep the current behavior (that is, block all modules), add `blacklist /sys/module` to globals.local. Fixes #6372. Reported-by: @GreatBigWhiteWorld Reported-by: @orzogc Reported-by: @krop Reported-by: @michelesr Suggested-by: @glitsj16 Tested-by: @flyxyz123
A Debian user reported that Steam was segfaulting when run with firejail after upgrading the nvidia driver to 367.44-2.
(Also glxgears behaves wrong with the steam profile)
The problematic line in the steam profile is the "noroot" setting, though I don't know why exactly this is causing issues.
The complete bug report is here.
The text was updated successfully, but these errors were encountered: