[GH-ISSUE #1045] GPU acceleration not working out of the box anymore with vglusers #710

Closed
opened 2026-05-05 06:29:28 -06:00 by gitea-mirror · 6 comments
Owner

Originally created by @ruany on GitHub (Jan 12, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1045

Seems like anything requiring GPU acceleration stopped working after a firejail update, as if --no3d is passed by default.

Using latest git version. GLXGears works fine outside of firejail. Other programs (chromium, wine) are also affected.

» glxinfo|head                 
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context, 
    GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, 
    GLX_ARB_fbconfig_float, GLX_ARB_multisample, GLX_EXT_buffer_age, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 

» firejail --debug --noprofile glxgears
Autoselecting /usr/bin/zsh as shell
Command name #glxgears#
DISPLAY :0.0, 0
Using the local network stack
Parent pid 27288, child pid 27289
Host network configured
Initializing child process
PID namespace installed
Mounting tmpfs on /run/firejail/mnt directory
Creating empty /run/firejail/mnt/seccomp.protocol file
Mounting read-only /bin, /sbin, /lib, /lib32, /lib64, /usr, /etc, /var
Mounting tmpfs on /var/lock
Mounting tmpfs on /var/tmp
Mounting tmpfs on /var/log
Mounting tmpfs on /var/lib/nginx
Mounting tmpfs on /var/lib/sudo
Create the new utmp file
Mount the new utmp file
installing a new /etc/machine-id
Cleaning /home directory
Sanitizing /etc/passwd, UID_MIN 1000
Sanitizing /etc/group, GID_MIN 1000
Disable /home/ruan/.config/firejail
Disable /run/firejail/network
Disable /run/firejail/bandwidth
Disable /run/firejail/name
Disable /run/firejail/x11
Remounting /proc and /proc/sys filesystems
Remounting /sys directory
Disable /sys/firmware
Disable /sys/hypervisor
Disable /sys/module
Disable /sys/power
Disable /sys/kernel/debug
Disable /sys/kernel/vmcoreinfo
Disable /proc/sys/fs/binfmt_misc
Disable /proc/sys/kernel/core_pattern
Disable /proc/sys/kernel/modprobe
Disable /proc/sysrq-trigger
Disable /proc/sys/vm/panic_on_oom
Disable /proc/irq
Disable /proc/bus
Disable /proc/config.gz
Disable /proc/sched_debug
Disable /proc/timer_list
Disable /proc/timer_stats
Disable /proc/kcore
Disable /proc/kallsyms
Disable /usr/lib/modules (requesterd /lib/modules)
Disable /boot
Disable /dev/port
Disable /dev/kmsg
Disable /proc/kmsg
Disable /sys/fs
DISPLAY :0.0, 0
Username ruan, groups 100, 7, 10, 14, 50, 92, 95, 81, 996, 108, 56, 150, 
starting application
LD_PRELOAD=(null)
Running 'glxgears'  command through /usr/bin/zsh
execvp argument 0: /usr/bin/zsh
execvp argument 1: -c
execvp argument 2: 'glxgears' 
Child process initialized
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)
  Value in failed request:  0x0
  Serial number of failed request:  31
  Current serial number in output stream:  32
monitoring pid 2

Sandbox monitor: waitpid 2 retval 2 status 256

Parent is shutting down, bye...
Originally created by @ruany on GitHub (Jan 12, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1045 Seems like anything requiring GPU acceleration stopped working after a firejail update, as if --no3d is passed by default. Using latest git version. GLXGears works fine outside of firejail. Other programs (chromium, wine) are also affected. ``` » glxinfo|head name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 server glx extensions: GLX_ARB_context_flush_control, GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, GLX_ARB_multisample, GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, » firejail --debug --noprofile glxgears Autoselecting /usr/bin/zsh as shell Command name #glxgears# DISPLAY :0.0, 0 Using the local network stack Parent pid 27288, child pid 27289 Host network configured Initializing child process PID namespace installed Mounting tmpfs on /run/firejail/mnt directory Creating empty /run/firejail/mnt/seccomp.protocol file Mounting read-only /bin, /sbin, /lib, /lib32, /lib64, /usr, /etc, /var Mounting tmpfs on /var/lock Mounting tmpfs on /var/tmp Mounting tmpfs on /var/log Mounting tmpfs on /var/lib/nginx Mounting tmpfs on /var/lib/sudo Create the new utmp file Mount the new utmp file installing a new /etc/machine-id Cleaning /home directory Sanitizing /etc/passwd, UID_MIN 1000 Sanitizing /etc/group, GID_MIN 1000 Disable /home/ruan/.config/firejail Disable /run/firejail/network Disable /run/firejail/bandwidth Disable /run/firejail/name Disable /run/firejail/x11 Remounting /proc and /proc/sys filesystems Remounting /sys directory Disable /sys/firmware Disable /sys/hypervisor Disable /sys/module Disable /sys/power Disable /sys/kernel/debug Disable /sys/kernel/vmcoreinfo Disable /proc/sys/fs/binfmt_misc Disable /proc/sys/kernel/core_pattern Disable /proc/sys/kernel/modprobe Disable /proc/sysrq-trigger Disable /proc/sys/vm/panic_on_oom Disable /proc/irq Disable /proc/bus Disable /proc/config.gz Disable /proc/sched_debug Disable /proc/timer_list Disable /proc/timer_stats Disable /proc/kcore Disable /proc/kallsyms Disable /usr/lib/modules (requesterd /lib/modules) Disable /boot Disable /dev/port Disable /dev/kmsg Disable /proc/kmsg Disable /sys/fs DISPLAY :0.0, 0 Username ruan, groups 100, 7, 10, 14, 50, 92, 95, 81, 996, 108, 56, 150, starting application LD_PRELOAD=(null) Running 'glxgears' command through /usr/bin/zsh execvp argument 0: /usr/bin/zsh execvp argument 1: -c execvp argument 2: 'glxgears' Child process initialized 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) Value in failed request: 0x0 Serial number of failed request: 31 Current serial number in output stream: 32 monitoring pid 2 Sandbox monitor: waitpid 2 retval 2 status 256 Parent is shutting down, bye... ```
gitea-mirror 2026-05-05 06:29:28 -06:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@ruany commented on GitHub (Jan 12, 2017):

I've looked into fs_dev.c and the files mentioned there (/dev/nvidia0, /dev/nvidiactl) are inaccessible. The entry which is spelled incorrectly /dev/nvidia-modset is accessible at /dev/nvidia-modeset ("Invalid argument" instead of "Permission denied")

cat: /dev/nvidia0: Permission denied
cat: /dev/nvidiactl: Permission denied
cat: /dev/nvidia-modeset: Invalid argument

Strangely the blacklisted files aren't mentioned at all in the --debug output.

Running firejail --noprofile --noblacklist=/dev/nvidia0 still results in "Permission denied" error.

Also, --private-dev seems to make no difference.

<!-- gh-comment-id:272088053 --> @ruany commented on GitHub (Jan 12, 2017): I've looked into `fs_dev.c` and the files mentioned there (`/dev/nvidia0`, `/dev/nvidiactl`) are inaccessible. The entry which is spelled incorrectly `/dev/nvidia-modset` is accessible at `/dev/nvidia-modeset` ("Invalid argument" instead of "Permission denied") ``` cat: /dev/nvidia0: Permission denied cat: /dev/nvidiactl: Permission denied cat: /dev/nvidia-modeset: Invalid argument ``` Strangely the blacklisted files aren't mentioned at all in the `--debug` output. Running `firejail --noprofile --noblacklist=/dev/nvidia0` still results in "Permission denied" error. Also, `--private-dev` seems to make no difference.
Author
Owner

@ruany commented on GitHub (Jan 12, 2017):

Problem is that /dev/nvidia0 is 0660 and is owned by vglusers. When I launch firejail I lose the vglusers group for some reason.

The problem isn't in fs_dev.c, it seems, recompiling it without those entries has no effect on the bug.

<!-- gh-comment-id:272089048 --> @ruany commented on GitHub (Jan 12, 2017): Problem is that /dev/nvidia0 is `0660` and is owned by `vglusers`. When I launch firejail I lose the vglusers group for some reason. The problem isn't in `fs_dev.c`, it seems, recompiling it without those entries has no effect on the bug.
Author
Owner

@netblue30 commented on GitHub (Jan 12, 2017):

OK, as I understand it:

  • /dev/nvidia-modeset should be /dev/nvidia-modset

  • I should preserve user/group ownership on nvidia files in /dev, I am currently setting them as root.

Can you please do a "ls -l /dev" on your system, thanks.

<!-- gh-comment-id:272185807 --> @netblue30 commented on GitHub (Jan 12, 2017): OK, as I understand it: - /dev/nvidia-modeset should be /dev/nvidia-modset - I should preserve user/group ownership on nvidia files in /dev, I am currently setting them as root. Can you please do a "ls -l /dev" on your system, thanks.
Author
Owner

@ruany commented on GitHub (Jan 12, 2017):

  1. /dev/nvidia-modset should be /dev/nvidia-modeset (other way around)
  2. Permissions are fine actually, I'm just somehow losing access to a group once firejail is launched

This is the problem:

ruan@desktop:~ » groups
lp wheel uucp games dbus audio storage users vboxusers wireshark plugdev vglusers

ruan@desktop:~ » firejail --noprofile
Parent pid 56908, child pid 56909
Child process initialized
Failed to connect to bus: Permission denied
ruan@desktop:~ » groups
lp wheel uucp games dbus audio storage users vboxusers wireshark plugdev

This doesn't seem to be a regression in firejail as I first thought it was. This happened after a reboot.

ruan@desktop:~ » ls -l /dev/nvidia*
crw-rw---- 1 root 1015 195,   0 Jan 12 09:05 /dev/nvidia0
crw-rw---- 1 root 1015 195, 255 Jan 12 09:05 /dev/nvidiactl
crw-rw-rw- 1 root root 195, 254 Jan 12 09:05 /dev/nvidia-modeset
ruan@desktop:~ » stat /dev/nvidia0
  File: /dev/nvidia0
  Size: 0         	Blocks: 0          IO Block: 4096   character special file
Device: 6h/6d	Inode: 14669       Links: 1     Device type: c3,0
Access: (0660/crw-rw----)  Uid: (    0/    root)   Gid: ( 1015/ UNKNOWN)
Access: 2017-01-12 09:05:43.567628158 +0200
Modify: 2017-01-12 09:05:43.567628158 +0200
Change: 2017-01-12 15:24:45.594853065 +0200
 Birth: -

Now I can see the actual cause of the problem. /etc/group is different after firejail is launched.

It seems like all groups with ID > 1000 are removed from /etc/group by firejail.

<!-- gh-comment-id:272191325 --> @ruany commented on GitHub (Jan 12, 2017): 1) /dev/nvidia-modset should be /dev/nvidia-modeset (other way around) 2) Permissions are fine actually, I'm just somehow losing access to a group once firejail is launched This is the problem: ``` ruan@desktop:~ » groups lp wheel uucp games dbus audio storage users vboxusers wireshark plugdev vglusers ruan@desktop:~ » firejail --noprofile Parent pid 56908, child pid 56909 Child process initialized Failed to connect to bus: Permission denied ruan@desktop:~ » groups lp wheel uucp games dbus audio storage users vboxusers wireshark plugdev ``` This doesn't seem to be a regression in firejail as I first thought it was. This happened after a reboot. ``` ruan@desktop:~ » ls -l /dev/nvidia* crw-rw---- 1 root 1015 195, 0 Jan 12 09:05 /dev/nvidia0 crw-rw---- 1 root 1015 195, 255 Jan 12 09:05 /dev/nvidiactl crw-rw-rw- 1 root root 195, 254 Jan 12 09:05 /dev/nvidia-modeset ruan@desktop:~ » stat /dev/nvidia0 File: /dev/nvidia0 Size: 0 Blocks: 0 IO Block: 4096 character special file Device: 6h/6d Inode: 14669 Links: 1 Device type: c3,0 Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 1015/ UNKNOWN) Access: 2017-01-12 09:05:43.567628158 +0200 Modify: 2017-01-12 09:05:43.567628158 +0200 Change: 2017-01-12 15:24:45.594853065 +0200 Birth: - ``` Now I can see the actual cause of the problem. /etc/group is different after firejail is launched. It seems like all groups with ID > 1000 are removed from /etc/group by firejail.
Author
Owner

@ruany commented on GitHub (Jan 12, 2017):

So now that I know I can easily solve the problem by editing /etc/group and making vglusers GID < 1000, I'd just like to know why groups with GID > 1000 (GID_MIN) are removed (by src/firejail/restrict_users.c). Is it for security reasons?

<!-- gh-comment-id:272194451 --> @ruany commented on GitHub (Jan 12, 2017): So now that I know I can easily solve the problem by editing `/etc/group` and making vglusers GID < 1000, I'd just like to know why groups with GID > 1000 (`GID_MIN`) are removed (by `src/firejail/restrict_users.c`). Is it for security reasons?
Author
Owner

@netblue30 commented on GitHub (Jan 13, 2017):

Fixed /dev/nvidia-modeset, thanks!

Yes, some of the users and groups under 1000 (500 on some systems) have high privileges, so I wipe them out.

<!-- gh-comment-id:272442620 --> @netblue30 commented on GitHub (Jan 13, 2017): Fixed /dev/nvidia-modeset, thanks! Yes, some of the users and groups under 1000 (500 on some systems) have high privileges, so I wipe them out.
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#710
No description provided.