udisks(-zram) installs a udev rule plus a systemd service that are dangerous

[vpodzime]

trafficstars

There's the following rule in data/80-udisks2.rules:

  # Zram devices setup
  KERNEL=="zram[0-9]", ENV{SYSTEMD_WANTS}="zram-setup@zram%n.service", TAG+="systemd"

and this is what the [email protected] does:

[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=-/usr/lib/zram.conf.d/%i-env
ExecStart=-/bin/sh -c 'echo $ZRAM_NUM_STR > /sys/class/block/%i/max_comp_streams'
ExecStart=-/bin/sh -c 'echo $ZRAM_DEV_SIZE > /sys/class/block/%i/disksize'
ExecStart=-/bin/sh -c '[ "$SWAP" = "y" ] && mkswap /dev/%i && swapon /dev/%i'
ExecStop=-/bin/sh -c 'echo 1 > /sys/class/block/%i/reset'

The purpose of the above is that together with files under /etc/modules-load.d/ and /etc/modprobe.d/ udisks allows creation of persitent compressed swap using zram devices (using the Activate() method on them). By making sure the zram module is loaded on boot, with the right options to create the particular number of devices, and the udev rule together with the systemd service setting up the device as a swap device.

However, the udev rule and the systemd service are triggered for any zram device no matter which way it is created. So if somebody has the udev rule and the systemd service installed and they create a zram device manually or by some other means, they may hit various issues.

[enihcam]

To me it sounds like using udev against out-of-control devices is dangerous in general. In that case, the solution would be to just simply let users to manage starting/stoping the service.

[tbzatek]

Also, since the udev rules are included in the master 80-udisks2.rules it would make sense to move it to its own file as the udisks2-zram module and its systemd service may not be compiled or installed at all.

[tbzatek]

I've put several precautionary measures in place, please check the linked #791 pull request. There's more for improvement but these changes should cover this ticket.