If 1) service has [Service] DevicePolicy=closed DeviceAllow=char-foobar rw # or "char-*", or "/dev/foobar*"
2) foobar module is not loaded and foobar major is not known to kernel yet at the moment service started, 3) some time after service was started, foobar module is loaded (e.g. triggered by hotplug);
Then service cgroup/device won't be adjusted and service won't be able to access newly-created /dev/foobar123 device.
(quick check [assuming loop module is not in use]: rmmod loop; systemctl start test1; sleep 10s; modprobe loop; sleep 10s; cat /sys/fs/cgroup/devices/system.slice/test1.service/devices.list)
It can be fixed by `systemctl restart`, however it is disruptive and undesirable (and it is not automated). systemd/udev should be able to detect when new devices/majors registered, recheck DeviceAllow= entries and add missing entries to $cg/devices.allow.
Potential problem: if I have not misread kernel sources, rebuilding device list from scratch (echo a >$cg/devices.{allow,deny}) fails with EINVAL if "css_has_online_childrens" (whatever it means, sub-cg?); however, there are no such problem if you add/remove individual devices (echo c 1:2 rwm >$cg/devices.allow) to existing (non-blanket-allow-all) policy.
Tested only on jessie/systemd-215, but quick look at git master sources suggests it was not changed/improved later.
[Unit] Description=test device policy propagation [Service] DevicePolicy=closed DeviceAllow=block-loop rw ExecStart=/bin/sleep inf #ExecStart=/bin/sh -c 'while sleep 10; do [ -e /dev/loop0 ] || continue; dd count=1 if=/dev/loop0 of=/dev/null;done' Type=simple
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
