what exactly does --device=dri open?

[Simon McVittie]

On Tue, 11 Feb 2020 at 21:37:29 +0000, Winnie Poon wrote:
> I would like to understand more what this --device=dri does.

For the most correct version, without anyone else's interpretation
(not even mine), see the flatpak source code. (common/flatpak-run.c,
look for FLATPAK_CONTEXT_DEVICE_DRI)

This currently means the /dev/dri directory (used by GPUs with open-source
drivers, most commonly AMD and Intel GPUs on PC hardware), plus its
closest equivalents in the proprietary NVIDIA and Mali drivers.

> We did open a hole "--device=dri" for OpenGL to work, but it looks
> like this --device=dri also opens up a lot of things inside the sandbox. 

It provides working DRI GPU drivers (for OpenGL, OpenGL ES, OpenCL,
Vulkan, VA-API, VDPAU and similar things with open-source drivers),
plus the closest equivalents in some proprietary GPU drivers (again for
OpenGL, OpenCL and so on).

> It seems like with this hole "--device=dri", from inside the sandbox we can
> directly access the GPU

Well, yes, that's exactly what DRI is for - it's the Direct Rendering
Interface, for direct access to GPUs.

> Is there a way to open up a "smaller" hole?

Not if you want accelerated OpenGL, etc. to work.

If lower-performance/less-power-efficient software OpenGL (llvmpipe)
is acceptable to you, you can disable --device=dri. In this case, other
things that rely on GPU access (OpenCL, Vulkan, VA-API, etc.) will
either run on the CPU with lower performance or power-efficiency, or
not work at all, depending whether they have a software fallback path
like OpenGL does.

> Is it safe/secure to use "--device=dri" which seems to break open the sandbox
> and allow the app to reach out to do a lot of things as if it's outside the
> sandbox?

Only you can say what is an acceptable level of risk/attack surface for
your use-cases.

    smcv