Hi,I would like to share some info about particular DENIED messages that happen on the machines with NVIDIA graphics hardware and proprietary divers. This does not happen with integrated Intel chips.
You might have seen these kind of denies: ```type=AVC msg=audit(1517738575.272:418): apparmor="DENIED" operation="open" profile="/usr/bin/glxgears" name="/home/vincas/#12976887" pid=21444 comm="glxgears" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
type=AVC msg=audit(1517738575.272:419): apparmor="DENIED" operation="mknod" profile="/usr/bin/glxgears" name="/home/vincas/.glvndMxWhdd" pid=21444 comm="glxgears" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
type=AVC msg=audit(1517738575.272:420): apparmor="DENIED" operation="open" profile="/usr/bin/glxgears" name="/tmp/#2492715" pid=21444 comm="glxgears" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
type=AVC msg=audit(1517738575.272:421): apparmor="DENIED" operation="mknod" profile="/usr/bin/glxgears" name="/tmp/.glvndFEnPtV" pid=21444 comm="glxgears" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
type=AVC msg=audit(1517738575.316:422): apparmor="DENIED" operation="mknod" profile="/usr/bin/glxgears" name="/tmp/.gls5YBRD" pid=21444 comm="glxgears" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
type=AVC msg=audit(1517738575.316:423): apparmor="DENIED" operation="mkdir" profile="/usr/bin/glxgears" name="/home/vincas.nv/" pid=21444 comm="glxgears" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
``` To make this more readable, extracted paths of interest: /home/vincas/#12976887 /home/vincas/.glvndMxWhdd (.glvnd*) /tmp/#2492715 /tmp/.gls5YBRD /home/vincas.nv/So far it's only denies for rw/c permissions. After allowing to write to theses paths with these rules:
```
owner /tmp/#[0-9]* rw,
owner /tmp/.gl* rw,
owner @{HOME}/#[0-9]* rw,
```
new denies appears for file_mmap:
```
type=AVC msg=audit(1517739204.123:468): apparmor="DENIED"
operation="file_mmap" profile="/usr/bin/glxgears"
name="/home/vincas/#12976887" pid=23170 comm="glxgears"
requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
``` ```type=AVC msg=audit(1517739204.163:470): apparmor="DENIED" operation="file_mmap" profile="/usr/bin/glxgears" name="/tmp/.glhWbOWH" pid=23170 comm="glxgears" requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000
```The peculiar path `/home/vincas.nv/` suggested a bug, and Debian bug report exists for that [0].
After some digging, it appears that: 1. NVIDIA's libGL tries to mmap() some temporary files for execution.2. Additionally, if it fails to do that in the primary locations, it tries to create $USER.nv directory and try that there.
For issue #2, it's a confirmed NVIDIA path concatenation bug, and probably be fixed and probably can be more or less ignored.
For issue #1, it seems that is not a bug, but works as designed, for implementing some sort of optimization, that can be disabled with __GL_WRITE_TEXT_SECTION=0 env. var.
Both #1 and #2 are confirmed in NVIDIA development forums [1]. Now the question for AppArmor side of affairs, I see two questions:Q1: What's the deal with these /home/vincas/#12976887 paths? Sysdig fails to show events for that kind of paths (or I fail to catch them). Is is some sort of failure from Linux/AppArmor kernel side? Some propiertary-binany-driver-blob magic? I does look like same attempts as with .gl* mentioned files above.
Q2. What could be done with these deny messages in AppArmor policies?For Q2, I'm suggesting to add rules in `abstractions/nvidia` to deny all mmaps, _maybe_ allow to write @{HOME}/.glvnd*, and probably deny completely all these seems-like-bogus #[0-9] writes too.
This might produce some sort of performance degradation (I do not have any numbers) if these mmaps() are denied for optimizations, but I doubt we have a lot of high performance 3D users currently... At the time when this could be discovered as regression for some applications, maybe AppArmor (hint hint) will have way to override denies in policy file for specific cases.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888028[1] https://devtalk.nvidia.com/default/topic/1029338/linux/libgl-tries-to-create-home-user-nv-directory-after-failing-to-mmap-tmp-gl-for-execution/post/5235879/#5235879
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
