libdrmtap 0.5.10

Security: a setuid, setgid or file-capability binary ignores the environment and loads no GL

When the library picks the card itself (no device_path in the config), it read
DRM_DEVICE whenever the process was not root. A program that holds CAP_SYS_ADMIN
through file capabilities, is setuid to a user other than root, or is setgid, runs
with an environment the invoking user sets, so that user could choose which node it
opens. The library now reads DRM_DEVICE and its own DRMTAP_* variables with
secure_getenv(), which returns nothing in a setuid (root or not), setgid or
file-capability binary. Root was already covered for DRM_DEVICE (0.4.11). A program
can still turn on logging with drmtap_config.debug.

In such a binary the library also no longer loads the GL libraries for the EGL detile:
they are third-party code that reads its own environment variables. Grabs there take
the paths of a build without EGL: a CPU deswizzle where one exists, a fail-closed error
where none does (measured on i915: -ENOTSUP, with an error that names the cause), and a
framebuffer that states no modifier is read as linear. 0.5.9 detiled in that process.
A consumer that needs the detile runs unprivileged and grabs through the helper, which
loads no GL. A process that runs as root without a setuid bit is unchanged.

The README said DRM_DEVICE is ignored for "root / CAP_SYS_ADMIN" callers; it now
names the cases the code covers. SECURITY.md said the variable cannot redirect which
device the helper opens; in the helper model it can, because the helper opens the path
the unprivileged library picked, and the helper still refuses anything outside
/dev/dri/.