# Restrict the NVIDIA device nodes to the accounts that should have the GPU.
#
# The nvidia driver creates /dev/nvidia* in the kernel itself. It does not
# register them in sysfs and it does not let udev process them:
#
#   $ udevadm info --name=/dev/nvidiactl
#   Unknown device "/dev/nvidiactl": No such device
#
# So a rule that matches the device nodes - KERNEL=="nvidiactl" and so on -
# never runs, because udev never evaluates a rule for a device it does not
# know about. That is also why the nodes are 0666: nothing in
# /usr/lib/udev/rules.d/71-nvidia.rules sets a MODE or a GROUP, and the driver
# created them world-accessible. A first attempt at this file was exactly those
# node-matching rules; it was inert, and only the permission check afterwards
# showed it.
#
# What udev *does* know about is the PCI device. This file therefore hooks the
# event where the driver binds, which is after modprobe has created the nodes,
# and fixes them from a script. It sorts after the driver's own 71-nvidia.rules
# so the module-load rules there have already run.
#
# `nvidia-restrict-permissions` is the script that does the work. Keeping it
# out of the rule file matters: a RUN key with a shell pipeline is one long line
# to review, and this is a security boundary.
#
# The video group already contains `ollama`, which is the account that actually
# opens the GPU - the agent talks to ollama over HTTP and runs `nvidia-smi`, it
# does not open these nodes itself. `umbra-poc` is added to the group by
# nvidia-device-access.sh, not by hand: `nvidia-smi` opens /dev/nvidia0,
# /dev/nvidiactl and /dev/nvidia-uvm, so without it the agent would still start,
# still heartbeat, and report a machine with no GPU - a failure that presents as
# a scheduling problem and is a permissions one.

ACTION=="bind", SUBSYSTEM=="pci", ATTRS{vendor}=="0x10de", RUN+="/usr/lib/udev/nvidia-restrict-permissions --wait=30"
ACTION=="add", DEVPATH=="/bus/pci/drivers/nvidia", RUN+="/usr/lib/udev/nvidia-restrict-permissions --wait=30"