Read-only interface for block devices

[Alberto Donato]

Hi,

when running a rack controller, the MAAS snap needs to be able to read details about disks and partitions, to report details about system hardware and configuration.

Specifically, we run commands such as lsblk, udevadm, blockdev to get disk details, partition sizes and types.

Currently, we're using the "block-devices" interface, but this has some drawbacks:
1) it's more powerful than what we need, as we only need read-only access
2) it doesn't provide access to individual partitions for block devices

Would it be possible to have a "block-devices-observe" interface, which provides that?

Thanks

[Jamie Strandboge (jdstrand)]

The 'block-devices' interface is meant for things like smartctl and hdparm (or flashing tools) to perform actions on raw disks. It says specifically: "Only allow raw disk devices; not loop, ram, CDROM, generic SCSI, network, tape, raid, etc devices or disk partitions"

So block-devices should not be extended to individual partitions.

hardware-observe is meant to allow lsblk and querying udevadm, have you tried that? /sbin/blockdev is not included in hardware-observe and would need to be added, but you might be able to use stage-packages in the meantime.

[Ondrej Kubik (ondrak)]

I have similar problem, though with write permissions
On one of the hw we work with, nvram is emulated as one partition on emmc.
There is daemon in user-space which runs at the start of the device and parses through raw nvram partition and sync its content to directory (SNAP_COMMON) from where we then share it using content interface. This daemon snap needs access to only single partition. So while block-devices interface does the trick, it opens permissions too much. So instead we use system-files to permit access to single partition.
Another use-case we have is with boot environment variables. Boot env is stores in raw format in dedicated partition(s). In order to trigger actions like factory reset we need to alter content of this partition. Again giving access to all block-devices is too permissive. Especially since we have have two partitions for boot environment ( second one being backup). So giving access only to primary one, while keeping backup intact would be preferred way.

Given both cases are quite hw specific, syntax where gadget snap would have language to describe permitted partitions and define slots for them, much like for gpios, would probably fit the bill here.

[Launchpad Janitor (janitor)]

[Expired for snapd because there has been no activity for 60 days.]

[Jamie Strandboge (jdstrand)]

https://github.com/snapcore/snapd/pull/7768

[Zygmunt Krynicki (zyga)]

The raw-volume interface has been merged and released. Marking the bug as fix released.