Freemkv: optical-drive (write), hardware-observe, dbus slot

store-requests privileged-interfaces
1 
name: freemkv
description: Open-source (MIT) DVD, Blu-ray and UHD disc backup tool. A single
  Rust binary: a GTK4/libadwaita desktop app that also includes the full CLI.
snapcraft: https://github.com/freemkv/freemkv/blob/dev/snap/snapcraft.yaml
upstream: https://github.com/freemkv/freemkv
upstream-relation: maintainer
plugs:
  optical-write:
    interface: optical-drive
    attributes:
      write: true
    request-type: auto-connection
    reasoning: freemkv talks to the optical drive directly with SCSI commands
      via SG_IO on /dev/sg* and /dev/sr*. The kernel requires the device to be
      opened read-write for SG_IO, so even reading a disc needs write: true;
      the read-only optical-drive plug is not enough. It also locks the tray
      during a rip, ejects the disc afterwards, and on supported drives sends
      vendor-specific commands to enable raw reads. It does not burn or write
      to discs. Reading discs is the snap's core function; without this
      connection it cannot do anything. Precedent:
      https://forum.snapcraft.io/t/write-access-to-optical-drive/8289
  hardware-observe:
    request-type: auto-connection
    reasoning: freemkv reads /sys/class/scsi_generic and /sys/block to find
      optical drives, match sg and block devices, and size its reads
      (queue/max_hw_sectors_kb). Needed to list the user's drives at all.
slots:
  freemkv-dbus:
    interface: dbus
    attributes:
      bus: session
      name: org.freemkv.FreeMKV
    request-type: manual-connection
    reasoning: freemkv is a GTK4 desktop application. GtkApplication owns its
      application ID on the session bus for single-instance handling and
      desktop integration. The bus name matches the snap's common-id, desktop
      file and AppStream ID. Without this slot, confinement denies the app
      ownership of its bus name.
2

This request has been added to the queue for review by the @reviewers team.

3

Given the functionality of the application, it makes sense for freemkv to auto-connect to optical-drive with write attribute and hardware-observe interface. Hence, +1 from me. Dbus access is already granted.

What do other reviewers think?

4

Hello all :slight_smile:

I also think that the requests for both interfaces are reasonable, so +1 from my side, for auto-connecting optical-drive (with write attribute ) and hardware-observe interfaces to the freemkv snap.

5

+2 votes for, 0 votes against, Granting auto-connection of optical-drive and hardware-observe interfaces to freemkv snap. New revision of the snap should pass the automated reviews.

6

Hi reviewers,

I am supporting this request as an active user and tester running Ubuntu 26.04.1 LTS on bare-metal hardware.

My Use Case: I use FreeMKV to back up and digitize my personal physical DVD and Blu-ray collection to uncompressed .mkv files for local streaming and archival.

Hardware & Access Needs: My system uses two physical optical drives: an LG GGC-H20L (/dev/sr0) and a TSSTcorp SN-B063D (/dev/sr1).

In order to query optical disc structures, perform disc indexing, and handle raw SCSI pass-through commands (SG_IO) across both drives, the application requires direct low-level hardware access. Standard restricted sandbox permissions prevent the app from recognizing or reading physical optical discs properly.

Having FreeMKV available via the Snap Store with the requested permissions granted would make it much easier to install, run, and auto-update safely on Ubuntu.

Thanks for taking the time to review this request!