[GH-ISSUE #3144] Avoiding indirect GLX for sandboxed Wine app #1975

Closed
opened 2026-05-05 08:38:25 -06:00 by gitea-mirror · 13 comments
Owner

Originally created by @haarp on GitHub (Jan 14, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3144

Greetings,

I have an untrusted Windows app running under Wine in need of 3D acceleration. When I remove its ability to use the net with --network=none, I'm getting

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)

After some googling, it appears that starting X with the +iglx parameter (indirect GLX) seems to solve the problem. And indeed, it does! However, indirect GLX usually appears to be necessary to run 3D application over the network (which I'm not doing), and it is a possible security vulnerability.

I suspect that indirect GLX is needed because I disabled network access for my app. So I tried the alternative mentioned in the firejail manpage, which is --protocol=unix. This however makes the app not start at all.

I would like to avoid needing indirect GLX, but without giving the untrusted app network access. What are my options?

Thanks a lot!

Originally created by @haarp on GitHub (Jan 14, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3144 Greetings, I have an untrusted Windows app running under Wine in need of 3D acceleration. When I remove its ability to use the net with --network=none, I'm getting ``` X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) ``` After some googling, it appears that starting X with the `+iglx` parameter (indirect GLX) seems to solve the problem. And indeed, it does! However, indirect GLX usually appears to be necessary to run 3D application over the network (which I'm not doing), and it is a possible security vulnerability. I suspect that indirect GLX is needed because I disabled network access for my app. So I tried the alternative mentioned in the firejail manpage, which is ```--protocol=unix```. This however makes the app not start at all. I would like to avoid needing indirect GLX, but without giving the untrusted app network access. What are my options? Thanks a lot!
gitea-mirror 2026-05-05 08:38:25 -06:00
Author
Owner

@totaam commented on GitHub (Jan 14, 2020):

Try https://virtualgl.org/
All it needs is a socket connection to the real X11 server with GPU access.
This socket will only be used for opengl commands so it is pretty narrow and safe.

<!-- gh-comment-id:574194656 --> @totaam commented on GitHub (Jan 14, 2020): Try https://virtualgl.org/ All it needs is a socket connection to the real X11 server with GPU access. This socket will only be used for opengl commands so it is pretty narrow and safe.
Author
Owner

@haarp commented on GitHub (Jan 15, 2020):

Thanks for your suggestion, totaam.

I've since found out that net=none was not responsible for my program failing with X errors. It was nogroups in Wine's profile, probably because it removed the video group. Is there a way to selectively keep groups?

<!-- gh-comment-id:574809175 --> @haarp commented on GitHub (Jan 15, 2020): Thanks for your suggestion, totaam. I've since found out that `net=none` was not responsible for my program failing with X errors. It was `nogroups` in Wine's profile, probably because it removed the `video` group. Is there a way to selectively keep groups?
Author
Owner

@ghost commented on GitHub (Jan 16, 2020):

Is there a way to selectively keep groups?

@haarp You can try the allusers option.

<!-- gh-comment-id:575008254 --> @ghost commented on GitHub (Jan 16, 2020): > Is there a way to selectively keep groups? @haarp You can try the `allusers` option.
Author
Owner

@haarp commented on GitHub (Jan 16, 2020):

@glitsj16

You can try the allusers option.

Yes, I've read that in the manpage. But adding allusers does not seem to make a difference, nor does it or nogroups have any options. The manpage is not clear how exactly allusers modifies behavior.

<!-- gh-comment-id:575026763 --> @haarp commented on GitHub (Jan 16, 2020): @glitsj16 > You can try the `allusers` option. Yes, I've read that in the manpage. But adding `allusers` does not seem to make a difference, nor does it or `nogroups` have any options. The manpage is not clear how exactly allusers modifies behavior.
Author
Owner

@ghost commented on GitHub (Jan 16, 2020):

@haarp I guess your only alternative for now is to use a wine.local with ignore nogroups or to use --ignore=nogroups in the command that starts this application. I have zero experience with wine. Cannot really judge whether or not this constitutes a bug in the profile. Do you see this behaviour in other wine applications that need 3D accel?

<!-- gh-comment-id:575105129 --> @ghost commented on GitHub (Jan 16, 2020): @haarp I guess your only alternative for now is to use a wine.local with `ignore nogroups` or to use `--ignore=nogroups` in the command that starts this application. I have zero experience with wine. Cannot really judge whether or not this constitutes a bug in the profile. Do you see this behaviour in other wine applications that need 3D accel?
Author
Owner

@Vincent43 commented on GitHub (Jan 16, 2020):

Generally on modern systemd based distro, static resource access control by groups (like video, audio, etc.) isn't used anymore so I think ignore nogroups is acceptable workaround for corner cases.

<!-- gh-comment-id:575257264 --> @Vincent43 commented on GitHub (Jan 16, 2020): Generally on modern systemd based distro, static resource access control by groups (like `video`, `audio`, etc.) isn't used anymore so I think `ignore nogroups` is acceptable workaround for corner cases.
Author
Owner

@haarp commented on GitHub (Jan 16, 2020):

@glitsj16 This problem appears in any Wine app using 3D acceleration. At least on Nvidia hardware, Intel hardware does not appear to be affected. I would say this is a bug in the Wine profile, yes.

<!-- gh-comment-id:575260796 --> @haarp commented on GitHub (Jan 16, 2020): @glitsj16 This problem appears in any Wine app using 3D acceleration. At least on Nvidia hardware, Intel hardware does not appear to be affected. I would say this is a bug in the Wine profile, yes.
Author
Owner

@Vincent43 commented on GitHub (Jan 16, 2020):

@haarp the problem is this can be fixed only by removing nogroups from wine profile which will reduce security for everyone regardless if they need it or not.

<!-- gh-comment-id:575264738 --> @Vincent43 commented on GitHub (Jan 16, 2020): @haarp the problem is this can be fixed only by removing `nogroups` from wine profile which will reduce security for everyone regardless if they need it or not.
Author
Owner

@rusty-snake commented on GitHub (Jan 16, 2020):

Suggestion:

# Cause issues with 3D acceleration with nVidia,
# comment or put 'ignore nogroups' in your wine.local.
nogroups
<!-- gh-comment-id:575292917 --> @rusty-snake commented on GitHub (Jan 16, 2020): Suggestion: ``` # Cause issues with 3D acceleration with nVidia, # comment or put 'ignore nogroups' in your wine.local. nogroups ```
Author
Owner

@haarp commented on GitHub (Jan 16, 2020):

@Vincent43 I'm aware if that. I'm not sure how to solve this properly myself. But please bear in mind that a modern distro does not imply systemd.

Further research revealed that for Nvidia GLX to work, the user needs access to /dev/nvidia0 and /dev/nvidiactl (possibly /dev/nvidia-modeset too, for apps that change the resolution?) which is usually handled by giving the video group rw rights to it, and adding users in need of 3D acceleration to this group.

This actually concerns any application wishing to do 3D acceleration on an Nvidia card (with the propietary drivers), it is not limited to Wine! Easily tested with firejail --nogroups glxgears.

So while @rusty-snake 's suggestion is a start (even if not very discoverable), it needs to be applied to all apps that might do 3D acceleration, and which currently have nogroups set.

<!-- gh-comment-id:575340928 --> @haarp commented on GitHub (Jan 16, 2020): @Vincent43 I'm aware if that. I'm not sure how to solve this properly myself. But please bear in mind that a modern distro does not imply systemd. Further research revealed that for Nvidia GLX to work, the user needs access to `/dev/nvidia0` and `/dev/nvidiactl` (possibly `/dev/nvidia-modeset` too, for apps that change the resolution?) which is usually handled by giving the `video` group rw rights to it, and adding users in need of 3D acceleration to this group. This actually concerns any application wishing to do 3D acceleration on an Nvidia card (with the propietary drivers), it is not limited to Wine! Easily tested with `firejail --nogroups glxgears`. So while @rusty-snake 's suggestion is a start (even if not very discoverable), it needs to be applied to all apps that might do 3D acceleration, and which currently have `nogroups` set.
Author
Owner

@Vincent43 commented on GitHub (Jan 17, 2020):

For nvidia even systemd may not help although I'm not sure. Perhaps you should add ignore nogroups to globals.local

<!-- gh-comment-id:575596880 --> @Vincent43 commented on GitHub (Jan 17, 2020): For nvidia even systemd may not help although I'm not sure. Perhaps you should add `ignore nogroups` to `globals.local`
Author
Owner

@haarp commented on GitHub (Jan 17, 2020):

For nvidia even systemd may not help although I'm not sure. Perhaps you should add ignore nogroups to globals.local

Yes, that's a good workaround for now. But I'm wondering how to properly fix this in the future, for everybody. Possibly by providing finer-grained control over user groups? 3D acceleration isn't the only use case where a group might be necessary for a certain task, while all other groups can be removed.

<!-- gh-comment-id:575604686 --> @haarp commented on GitHub (Jan 17, 2020): > For nvidia even systemd may not help although I'm not sure. Perhaps you should add ignore nogroups to globals.local Yes, that's a good workaround for now. But I'm wondering how to properly fix this in the future, for everybody. Possibly by providing finer-grained control over user groups? 3D acceleration isn't the only use case where a group might be necessary for a certain task, while all other groups can be removed.
Author
Owner

@rusty-snake commented on GitHub (Feb 10, 2020):

I'm closing here because the original question in answered.

<!-- gh-comment-id:584056023 --> @rusty-snake commented on GitHub (Feb 10, 2020): - #2042 - https://github.com/netblue30/firejail/wiki/Frequently-Asked-Questions#3d-acceleration-with-nvidia-hardware I'm closing here because the original question in answered.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1975
No description provided.