[systemd-devel] DeviceAllow and hotplugged devices/modules
Yuriy M. Kaminskiy
yumkam at gmail.com
Sun Mar 13 14:51:58 UTC 2016
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.
-------------- next part --------------
[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
More information about the systemd-devel
mailing list