On Tue, Dec 12, 2023 at 10:13:36AM -0800, Stanley Phoong wrote: > * What led up to the situation? > The transition of /dev/dri/renderD* from the video to the render > group in SystemD has led to issues due to the lack of a fixed GID for > render. This has impacted various projects and forced the community > to adopt workarounds some workarounds are potentially security hazard > (e.g. enabling privilege mode or root access to mitigate this issue) > This impacts Docker users and VM users the most.
I'm not necessarily opposed to allocating a fixed group ID in the 60000-64999 range for "render", but normally this sort of request would come from a maintainer of one of the relevant packages (i.e. the packages that currently create that group dynamically) so that I can be sure that the maintainers of relevant packages agree with this action and are prepared to take the necessary transitional steps. Are there any other Debian bug reports on this subject in which package maintainers have analysed the problem and agreed that this is what needs to be done? > Reference commit ID: > github.com/systemd/systemd/commit/4e15a7343cb389e97f3eb4f49699161862d8b8b2 > > Some examples of issues around this: > https://github.com/blakeblackshear/frigate/issues/7640 > > https://unix.stackexchange.com/questions/747523/docker-permissions-issue-accessing-dev-dri-device > https://github.com/linuxserver/docker-plex/issues/211 > > https://support.xilinx.com/s/question/0D52E00006mfsHaSAI/permission-denied-when-running-hardware > https://github.com/jellyfin/jellyfin/issues/9229 It's less than clear that the change you suggest would fix these issues. If what you're trying to do is to make sure that the "render" group has the same ID in the host and in containers, the change you suggest won't systematically achieve that, and there's really no way to achieve that. (After all, the host or the containers might not even be using a Debian-based distribution.) Maybe there's some other approach? -- Colin Watson (he/him) [[email protected]]
