FYI, the snapd package has been moved from community to AUR and is now avaialble here: https://aur.archlinux.org/packages/snapd. The package was adopted by @Aimilius (thanks!) and got updated to 2.30 release.
3 Likes
As a results of a review from one of the Arch TUs, the snapd AUR package was updated with the following changes (thanks to Emiel for doing the work!):
- /var/lib/snapd/snap -> /snap symlink was dropped
- snapd.socket is no longer restarted in post_upgrade (socket activation of snapd will likely no longer work right after upgrading, user has to restart the socket themselves)
The snapd ArchWiki page was also updated with notes on classic snaps.
I’ve synced snapd-git, so the changes are in both packages now.
1 Like
This makes the skype classic package fail to launch because of the missing symlink.
We are aware of this. The change was requested by one of Arch devs. Attempting to run a classic snap you should get a message with instructions on how to get it working. Also, there is a note in the wiki page https://wiki.archlinux.org/index.php/Snapd#Classic_snaps
Thanks I didn’t know that. But it would be nice if the application didn’t suddenly stop working after a packaging change. Maybe a post-install message in snapd might be good.
According to my knowledge, snapd is meant to update by updating core?
But this isn’t the case with Arch Linux.
For any change in git, have to rebuild it from AUR.
What are the limitation so far?
Snapd and core are different things. You update snapd from AUR and update core from snap: snap refresh core
1 Like
There are still some compile time decisions made. When they are gradually removed each distribution can choose to opt-into the refreshing of snapd directly from a snap.
Oh, and let me just say that @mborzecki’s work just today made it much easier to allow Arch to do this 
1 Like
As @zyga-snapd mentioned there is still some code that requires compile time configuration. While the pieces in Go rely on run time detection, snap-confine is in C and is currently and relies on various configure switches. There are some ideas about reducing this configuration, but it will obviously take some work and time to get it done.
1 Like
I an curious about Sandboxing.
As far i know sandboxing is done by AppArmor and AppArmor isn’t enable in Mainline kernel provided by Arch Linux.
So that mean the snap app aren’t in sandbox?
Though what are the advantages of sandboxing?
On snapd-git you should be able to run snap debug sandbox-features to see what kind of sandboxing elements are present on your system. Sandboxing without apparmor is not as strong as without it but it’s not an all-or-nothing game.
The benefits of sandboxing are, obviously, that it is harder to attack the system by installing a malicious application.
How secure is snap without AppArmor compared to Flatpak?
And can we see AppArmor being enabled by Default on Arch Linux?
I’m not an expert on flatpak confinement and I’m sure it has evolved since I last looked. Take what I write with a grain of salt.
Snapd without apparmor still uses device cgroups (so programs cannot use character and block devices), seccomp (so system calls or even system calls and their arguments are verified) and a mount namespace (so the filesystem view is different from other programs).
Still this leaves a big hole in access to files and the network, /home is there and can be accessed at will.
Flatpak really doesn’t compete in that space since it’s not compatible with anything but specific GTK apps that were patched or fixed to use GTK functions for picking files. Having said that flatpak, last time I looked, used a mount namespace where /home was not visible. Snaps use apparmor and, depending on the use of home interface, either allow or disallow access to parts of the home folder.
As for apparmor in Arch that’s a question to Arch developers. I don’t know if there is interest in enabling that. If you are keen perhaps you can push this motion forward?
1 Like
@mhall119 is our resident Flatpak expert, perhaps he could confirm or deny Zyga’s comments? 
(Just giving Michael the right to reply, I know this whole discussion is somewhat off-topic though the topic could be split by a mod to deal with that)
What’s the current status on re-exec in non-Ubuntu distros like Arch (I also asked about this here)?
Actually, I’m guessing this still applies 
Also, just spotted your comment, Zyga.
Yeah. I’m working on small changes that will remove the roadblocks. I have a small branch for that (I will open the PR back home, I’m on the go now). This will only leave Nvidia support code (and specifically the hard-coded choice on which integration style to support) and /media as the last blockers.
The /media code is easy to remove as a compile time decision. Nvidia is a bit more complex because it involves a lot of code and somewhat more complex migration code.
1 Like