Re: [PATCH] SELinux: Dontaudit access to dri devices

On 07/04/2026 11:11, Stefano Brivio wrote:

On Tue, 7 Apr 2026 10:27:04 +0200 Johannes Segitz wrote:

...

...

I did a quick spot check in Podman and found a few places where a fd might be leaked: https://github.com/containers/podman/pull/28434

That said I do not think any of these would explain an open /dev/dri path. I build podman with the change (and passt with the broader fd closing logic) and asked the reporter to test them. The denial is still shown with

On Thu, Apr 02, 2026 at 03:36:58PM +0200, Paul Holzinger wrote: this unfortunately Johannes, thanks for reporting back.

Paul, I was wondering: would there be a way to do something equivalent to that close_range() directly in Podman, before it starts pasta? I think it's a separate thread (or even a forked process) starting it, but I haven't really checked.

So this is the problem, because the golang runtime manages its own epoll fds. It is not safe to close all fds within go code. We have some work around, custom c init code which counts the fds before the go runtime kicks in but it is kinda fragile and the bigger issue is that we have many commands that may need access to leaked fds, i.e.: - podman run --preserve-fds - systemd socket activition - shell expansion via `<(<<<"somestring")` passes us a string such as "/dev/fd/63", useful to inline a string on a command which only reads a file. It is basically impossible to correctly figure this all out on the podman side without breaking certain use cases. The other issue is that in theory yes lets just close all fds after fork() and before calling exec() but again the go runtime does not allow us to simply fork/exec. Due its nature we are limited to just an exec API with little control over the steps between a fork() (well clone() actually) and exec(). There are ways to pass down fds via that API which the go std code will dup at the right fd numbers but it will by default not close all other fds. Ok, well there is a way using the go std lib, the ExtraFiles array accepts nil entries which means close this fd at this place, i.e. `ExtraFiles = []*os.File{nil,nil}` would result in closing fd 3 and 4. So in order to close all fds we would have to pass a slice with the size of all possible fds on linux which is just not great. And well the go runtime code then calls close() on every single one of them which would just add to much unnecessary overhead for each pasta start. -- Paul Holzinger