Uh, this opens a can of worms: unpriv users that can modify raw file systems that the linux kernel then mounts and accesses? yuck. kernel file system devs made very clear they don't intend their implementations to be robust against rogue file system images, but it's an entirely new can of worms to allow runtime access to unpriv users completely uncontrolled even while the image might be mounted!

udisks can write disk images to USB disks. what#s wrong with using that?

it's an entirely new can of worms to allow runtime access to unpriv users completely uncontrolled even while the image might be mounted!

A malicious USB drive, or any gadget that supports looking like a USB mass storage device, could already do that. If that's exploitable, it's already exploitable on systems that enable automounting. I don't think this opens up any new attack surface area.

Along the same lines but much more simply, as far as I can tell it's already possible to use udisksctl loop-setup to set up a loopback device pointing to a file you own and can write to. That doesn't require authentication if you're on a local seat. So it's already possible, as a local user, to mount a filesystem and subsequently write to the backing device.

If your system allow local users to automount filesystems, this attack surface is already present. Adding these permissions would not introduce any new attack surface. These permissions would just make it easier and safer for legitimate users to write to removable devices they plug in.

udisks can write disk images to USB disks. what#s wrong with using that?

There are many, many more disk-image-related tools (and scripts) built around writing to the underlying disk device, rather than asking udisks to do so.

My goal here was to make it safe for users to run dd if=some.img of=/dev/sda , without needing to use sudo, and thus without the risk of accidentally using the wrong device and overwriting the wrong disk.