I'm trying to get NemoClaw (our containerized image analysis microservice) running under a hardened AppArmor profile. The service needs GPU acceleration, but my profile keeps blocking access to the device node. The container logs show:
```
apparmor="DENIED" operation="open" profile="nemo-claw-container" name="/dev/nvidia0" pid=4471 comm="nemo-claw"
```
Here's my current profile fragment for the device access:
```
abi ,
include
profile nemo-claw-container flags=(attach_disconnected,mediate_deleted) {
include
include
include
# Container runtime necessities
mount,
umount,
signal,
unix,
# My attempt at allowing nvidia
/dev/nvidia0 rw,
/dev/nvidiactl rw,
/dev/nvidia-modeset r,
/dev/nvidia-uvm rw,
}
```
The container runs with `--device /dev/nvidia0:/dev/nvidia0`. The base abstractions are likely too permissive elsewhere, but that's a separate issue.
My specific questions:
* Is the `rw` mode sufficient, or do I need `rmw` or `mrw` for the device? The man pages are vague on the distinction for character devices.
* Are there any additional NVidia-specific device nodes or proc/sys files I'm missing? I've seen references to `/proc/driver/nvidia/gpus/*` and `/sys/bus/pci/devices/*` being needed.
* Should I be using an `owner` conditional, since the device node ownership changes based on host driver installation?
I need to lock this down properly for an audit, so "complain mode" and allowing all denies isn't an option. The chain of custody for the log analysis output requires a documented, restrictive profile.
Missed the owner/match clause. Your profile allows access but doesn't specify who owns it, so the container's /dev/nvidia0 might be a different inode. Add:
```
owner /dev/nvidia0 rw,
owner /dev/nvidiactl rw,
```
For the mode, `rw` is fine for char devs. `m` is for executable mapping, not needed here.
You'll also need the device major/minor in /sys and likely `/proc/driver/nvidia/` read. But fix the owner match first.
Pwn or be pwned.
The `owner` clause user481 mentioned is key. But I think you also need to allow the path `/dev/nvidia-uvm-tools`. I ran into that one too.
About the mode: on my system, `rmw` worked where just `rw` still got denials. The man page says `m` is for memory mapping, and CUDA does map device memory, so maybe that's why.