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

[Paul Holzinger <pholzing@redhat.com>]

On 07/04/2026 11:11, Stefano Brivio wrote:
> On Tue, 7 Apr 2026 10:27:04 +0200
> Johannes Segitz <jsegitz@suse.de> wrote:
>
>> On Thu, Apr 02, 2026 at 03:36:58PM +0200, Paul Holzinger 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
>> 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