On 11/11/16 20:09, Lennart Poettering wrote: > I have no idea what "slurm" is, but do note that the "devices" cgroup > controller has no future, it is unlikely to ever become available in > cgroupsv2.
This is unwelcome news, I think it is a simple and well contained MAC that has been available in systems without a full blown MAC like SELinux and with systemd support it has been very easy to set up. What will happen to DevicePolicy, DeviceAllow etc. directives? Or will systemd stick to cgroupsv1 forever? > Device access to local users is normally managed through ACLs on the > device node, via udev/logind's "uaccess" logic. Using the "devices" > cgroup controller for this appears pretty misguided... ACLs only limit access via the path that they are controlling, device cgroup controlled the whole system. And if you have a MAC system that can do that, it could perform the same task as ACLs but in a much better way. With cgroup you could also deny access to nodes that need to be available for interactive users (like TTYs, audio, input devices, GPUs, USB devices), but which are not useful for system services. Perhaps some sort of ACL could be constructed with the same effect. > Also, were does 195 come from? is that a hardcoded major of the > closed-source nvidia driver? Yuck, code really shouldn't hardcode > major/minor numbers these days... And sec The reason seems to be that kernel devs chose not to expose the required API to non-GPL modules, probably to give pressure to switch to GPL. As that has not happened, the situation is not optimal for end user point of view, but it's certainly within the devs' and module authors' rights to continue using incompatible licences. NVIDIA tackles this by shipping a SUID root helper nvidia-modprobe, which is of course even worse from security point of view but it works. This also highlights why having the device cgroup is a good idea, for example the helper could be fooled to create new device nodes without the ACLs. In my setup I have disabled the helper and the device nodes are created with tmpfiles, which means I'm able to remove CAP_MKNOD capability and any device cgroup 'm' rights from Xorg service running as non-root user. -Topi _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
