Request for ‘classic’ confinement for appspace-app

Hello, here are the reasons for our ‘classic’ confinement request:

  • For reboot: to access /sbin/shutdown command
  • AutoLaunch: to create a desktop entry file in ~/.config/autostart/ , i.e. “appspace-app.desktop” with command “/snap/bin/appspace-app”
  • To query network interface information
  • To query hardware information: dmidecode command
  • To query CPU information: ps command
  • To query memory information: access to /proc/meminfo
  • To query storage space information: df command
  • To query OS information: access to /etc/*-release ; /usr/lib/os-release ; /etc/openwrt_release
  • To access to file system to cache content to disk: createDirectory, checkFileDirectory, removeDirectory, enumerateDirectory, removeFile, moveFile
  • To fork child process and to kill it
  • Websocket server: to listen to TCP port 55530 (internal) and 55537 (external upon enabled)
1 Like

Also including appspace-app-dev and appspace-app-qa in this request; two separate snaps, so we can have the production listing ‘public’ and others as ‘unlisted’.

I think most of those requirements are supported by the various available interfaces. You probably want:

  • network-observe
  • hardware-observe
  • process-control
  • network-bind
  • system-files - configured for readonly access to the release files (*-release, os-relese, and openwrt_release)

To cache content you may use the available writable areas without classic.

The only thing here that I am unsure about is rebooting the system. Can you explain further what your app is designed to do and why it needs to reboot the system?

Auto-launching with .desktop files is supported by adding autostart: file.desktop and then adding a file with that name to $SNAP_USER_DATA/.config/autostart/file.desktop when your Snap is run.

1 Like

for os-release this should not be necessary … the hosts os-release should be accessible via:


(might need system-observe though. not sure … but thats not a highly privileged interface)

EDIT: rebooting works via the shutdown interface and the following dbus call:

    dbus-send --system --print-reply \
        --dest=org.freedesktop.login1 /org/freedesktop/login1 \
        "org.freedesktop.login1.Manager.Reboot" boolean:true
1 Like

Our app is digital signage, runs 24/7, single-application - we need to be able to do a daily reboot of the device.

Will review your recommendations with our engineering team and see where we end up - thanks for the insight.

Hello, given the “network-observe” interface, how to query the network information in terms of code level? Can you give an example in Node.js?

About the auto-start, by adding autostart: file.desktop in snap.yaml, do we still need to add the file “$SNAP_USER_DATA/.config/autostart/file.desktop” when our Snap is running? Wouldn’t that require us to maintain the access level? Does autostart in snap.yaml mean only allow us to create an entry startup file, but we still need to create it?


Tried using the recommendation in our app by adding “shutdown” interface and running the command:

dbus-send --system --print-reply
–dest=org.freedesktop.login1 /org/freedesktop/login1
“org.freedesktop.login1.Manager.Reboot” boolean:true

But the result is the command exit with this error:

Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.90" (uid=1000 pid=3702 comm=“dbus-send --system --print-reply --dest=org.freede” label=“snap.appspace-app.appspace-app (enforce)”) interface=“org.freedesktop.login1.Manager” member=“Reboot” error name="(unset)" requested_reply=“0” destination=“org.freedesktop.login1” (uid=0 pid=714 comm="/lib/systemd/systemd-logind " label=“unconfined”)\n

Though the snap.yaml file has the “shutdown” plug:

      - .....
      - system-observe
      - shutdown

Do we miss something?

and you did connect it with snap connect ... ?

It’s a snap.yaml extracted from the snap file.

After the snap file installation, I tried run the “snap connections” command, but the “shutdown” plug does not exists. Do I miss something?

What is “snap connect” used for? How to use it?


The “snap connections” showing that our app requesting for shutdown interface, but why the slot is empty? Does user have to manually connect it by command line after installation? Wouldn’t it become bad user experience? We actually want it to be automatically connected after installation.


you need to connect the plug to the slot …

We also need to call ‘df -P’ command to get storage space info (total, used and available space), what is the interface to use? This time we get a permission error:


from the top of my head i’d say mount-observe … but could also be system-observe, not sure

Thanks, this time we are playing audio and video in our app, but there is no sound heard at all. What is the interface to use for sound?

The various interfaces are documented at - please spend some time to read that page and familiarise yourself with them and the sub-documentation for each. As you can see on that page, for audio playback there is the appropriately named audio-playback interface.

After test using the ‘mount-observe’ or ‘system-observe’, notice that all the mount points are changed to become:

Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/loop8 56320 56320 0 100.00% /
udev 1986036 0 1986036 0.00% /dev
tmpfs 2014196 0 2014196 0.00% /dev/shm
/dev/sda5 61145932 15709316 42300872 28.00% /etc
tmpfs 2014196 0 2014196 0.00% /sys/fs/cgroup

The root ‘/’ information, which is originally to be the proper storage information (available, used, and 60GB total), is now incorrect (56MB only), then how to get the proper information?

check $SNAP_DATA it usually reflects the size of /

ogra@pi4:~$ snap run --shell fabrica.web
ogra@pi4:/home/ogra$ df -h $SNAP_DATA
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       458G   96G  339G  23% /var/snap

By checking $SNAP_DATA, is it always return 1 mounted path only?

When your snap uses strict confinement, it is run in a special mount namespace providing a known set of libraries from your chosen base snap (e.g. core18). This is generally a good thing, since it means your app will behave the same way on different systems. The base snap is a read only compressed file system, which is why / shows as having no free space.

If your aim is to determine how much space is available to store files in a particular directory, then the statfs system call is probably more appropriate. Even without snaps, there is no guarantee that the directory is on the same file system as /. In particular, multiplying the f_bsize and f_bavail members from the result should give you the amount of free space available in that part of the file system.

1 Like