[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