snapd

Read-only interface for block devices

Bug #1837369 reported by Alberto Donato
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
snapd
Fix Released
Undecided
Unassigned
snapd 2.43

Bug Description

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

See original description
Alberto Donato (ack)
description: updated
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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.

Changed in snapd:
status: New → Incomplete
Revision history for this message
Ondrej Kubik (ondrak) wrote :

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in snapd:
status: Incomplete → Expired
Adam Collard (adam-collard)
Changed in snapd:
status: Expired → New
status: New → Confirmed
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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

Changed in snapd:
status: Confirmed → In Progress
milestone: none → 2.43
Paweł Stołowski (stolowski)
Changed in snapd:
status: In Progress → Fix Committed
Revision history for this message
Zygmunt Krynicki (zyga) wrote :

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

Changed in snapd:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.