On 1/22/18 10:31 PM, Andreas Beckmann wrote:
On 2018-01-22 20:39, Vincas Dargis wrote:
It looks like some shared code actually wanted to create $HOME + / + .nv
directory, though accidentally skipped a slash.
Some nvidia driver components use ~/.nv/ as temporary storage, sounds
like something expects $HOME to contain a trailing slash ... probably
harmless without apparmor ...
Yep, kinda harmless as such (can be set to ignore on AppArmor with `deny` rule), but might be good fixing it if that
breaks caching behaviour or whatever.
Do you have XDG_CACHE_HOME set in the environment? (That's an
alternative location where to place the .nv directory.) Does it have a
trailing slash?
No, it's not set:
```
$ env | fgrep XDG_
XDG_VTNR=7
XDG_SESSION_ID=4
XDG_SESSION_TYPE=x11
XDG_DATA_DIRS=/usr/share:/usr/share:/usr/local/share
XDG_SESSION_DESKTOP=KDE
XDG_SESSION_CLASS=user
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_CURRENT_DESKTOP=KDE
XDG_SEAT=seat0
XDG_RUNTIME_DIR=/run/user/1000
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
```
Is the problem reproducible with something like glxinfo/glxgears? That
would simplify debugging.
I could reproduce it _only after creating AppArmor profile_ for glxgears.
And after some experimenting, it seems that if there is a rule:
owner /tmp/.gl* mrw,
It works OK without trying to create `user.nv` directory.
But if I remove 'm', meaning AppArmor will not allow to mmap() _for execution_,
like this:
owner /tmp/.gl* rw,
Same DENIED log message hits, also visible via sysdig:
$ sudo sysdig "proc.name=glxgears and evt.args contains vincas.nv"
357922 19:43:11.404657834 4 glxgears (16962) < mkdir res=-13(EACCES)
path=/home/vincas.nv
When 'm' is allowed, I actually can see that it's being mmap'ed with PROT_EXEC.
This is kinda off-topic, but why?
146765 19:31:41.363130865 1 glxgears (15280) > fstat fd=14(<f>/tmp/.glEwKU3e)
146781 19:31:41.363143600 1 glxgears (15280) > mmap addr=0 length=8192 prot=5(PROT_READ|PROT_EXEC)
flags=17(MAP_SHARED|MAP_32BIT) fd=14(<f>/tmp/.glEwKU3e) offset=0
146792 19:31:41.363152648 1 glxgears (15280) > mmap addr=0 length=8192 prot=3(PROT_READ|PROT_WRITE) flags=1(MAP_SHARED)
fd=14(<f>/tmp/.glEwKU3e) offset=0
146798 19:31:41.363156709 1 glxgears (15280) > close fd=14(<f>/tmp/.glEwKU3e)
Basically, if AppArmor profile does not allow to mmap() /tmp/.glEwKU3e files for execution (which is sensible thing to
do), some NVIDIA driver part _probably_ hits some code path with a bug that tries to create /home/user.nv/ directory in
response to that?
Again, there is no such problems if I run it on Intel, without `optirun`.
Anyway, please consider reporting this directly to NVIDIA, since we
cannot fix bugs in the binary components at all ...
See README.Debian in the driver for details.
Yeah, I'll report bug that they try to mmap() temporary user-writable files with PROT_EXEC, and still, `user.nv` seems
like a bug in that strange.. "use case".
P.S.
For the record, I've attached AppArmor profile for glxgears I've used for for
testing. To use it:
sudo cp usr.bin.glxgears /etc/apparmor.d/
sudo systemctl restart apparmor
Running glxgears afterwards should not produce DENIED events in kernel/audit
log.
Later, `owner /tmp/.gl* mrw,` rule cane be changed into `owner /tmp/.gl* rw,`
('m' removed), and after:
sudo systemctl restart apparmor
running glxgears (via optirun if needed to hit NVIDIA) should produce DENIED
event, and similar sysdig output.
# Last Modified: Tue Jan 23 19:01:05 2018
#include <tunables/global>
/usr/bin/glxgears {
#include <abstractions/X>
#include <abstractions/base>
#include <abstractions/nvidia>
# Main executable
/usr/bin/glxgears mr,
# System files
/dev/dri/ r,
/proc/driver/nvidia/params r,
/proc/modules r,
/sys/devices/pci[0-9]*/**/{device,subsystem,subsystem_device,subsystem_vendor,uevent,vendor}
r, # libdrm
/usr/lib/@{multiarch}/ld-*.so mr,
# User files
owner /tmp/#[0-9]* rw, # Also tries to mmap for execution!? although works
without allowing it.
owner /tmp/.gl* mrw, # Remove 'm' to reproduce attempt to create
/home/$user.nv/ directory
owner @{HOME}/#[0-9]* rw, # Also tries to mmap for execution!? although works
without allowing it.
owner @{HOME}/.Xauthority r,
owner @{HOME}/.nv/{,**/} w, # Allow to create ~/.nv directory tree if missing
owner @{HOME}/.nv/GLCache/ r,
owner @{HOME}/.nv/GLCache/**.toc rwk,
}
