multimedia: add home and var-tmp plugs for artifact writes - #21
multimedia: add home and var-tmp plugs for artifact writes#21seankingyang wants to merge 3 commits into
Conversation
The strictly-confined multimedia snap could not write capture artifacts anywhere a user or test harness can consume them: AppArmor denied writes under /var/tmp (used by the Checkbox certification harness) and $HOME (even as root), leaving only $SNAP_COMMON, which nobody uses. Add, at the top level so every app inherits them: - home: interactive users can save captures into their own home. - var-tmp (system-files, write /var/tmp): serves any tooling that stages files there, including the Checkbox camera jobs. Validated on an IGX Ubuntu Core 22 device: gst-launch and nvargus-nvraw captures land under /var/tmp with zero write-path AppArmor denials.
rmartin013
left a comment
rmartin013
left a comment
There was a problem hiding this comment.
This looks fine to me, but I am curious about @DocSepp feedback. In particular, I am wondering why is this change necessary in the context of your tests and not in ours. AFAIU, the gstreamer artifacts are as well recorded in $HOME.
|
Hey, thanks for this PR. These snaps aren't intended for end-users to use directly bu more as a guide to how to get started with developing snaps for tegra platforms. Since we don't have official snaps, we can't have the privileged interfaces auto-connect and I wanted to keep the needed interfaces to a minimum. In this case - as described in the README - the intention was to write the resulting files in the |
seankingyang
left a comment
seankingyang
left a comment
There was a problem hiding this comment.
For end users, storing images in the $HOME directory is more convenient because the gst command allows users to store files in any path accessible to normal users.
3 participants
Why
The
multimediasnap is strictly confined, and none of its apps canwrite capture artifacts anywhere a user or test harness can consume
them. Observed on Ubuntu Core 22 Jetson devices (AGX Orin, Orin Nano,
IGX) while running camera validation through the snap's
gst-launch/nvargus-nvrawapps:/var/tmp/...— even as root:apparmor="DENIED" operation="mknod" profile="snap.multimedia.gst-launch" name="/var/tmp/checkbox-ng/probe-test/probe.yuv" ... fsuid=0.(
/var/tmp/checkbox-ng/...is where the Checkbox certificationharness stores per-session artifacts.)
$HOMEare denied too:nvargus_nvrawreportsError FileOperationFailedafter a successful capture (thensegfaults in its error path);
gst-launch ... filesinkfails atpreroll with
Permission denied.$SNAP_COMMON(
/var/snap/multimedia/common/), which neither interactive usersnor test harnesses use.
The snap declares no
homeplug and nosystem-fileswrite access —this PR adds both, at the top level so every app inherits them:
home:— interactive users can save captures into their own home(owner-scoped by the interface: root writing into another user's
home stays denied, by design).
var-tmp(system-files, write/var/tmp) — deliberately thewhole of
/var/tmprather than a harness-specific subpath, so thesame snap serves any tooling that stages files there.
Validation
Validated 2026-07-18 on an Jetson AGX Orin Ubuntu Core 22 device by repacking the
installed snap with exactly these two plug entries (snap.yaml metadata
is what these snapcraft.yaml lines compile to) and connecting both
interfaces:
gst-launch nvarguscamerasrc(5 × 1080p NV12 frames) →/var/tmp/checkbox-ng/test/probe.yuv= 15,552,000 bytes.nvargus-nvraw→probe.nvraw= 4,155,392 bytes.previously-denied
$HOMEmknod now succeeds (clean before/after).Notes for users
Neither interface auto-connects on Ubuntu Core — post-install setup
needs:
Internal tracking: OEMQA-6808 (bug), OEMQA-6807 (proposal +
validation), canonical/checkbox#2699 (the Checkbox camera jobs that
consume these paths).