request-type: permission to upload the snap to the store using this interface, auto-connection if allowed
reasoning: adding per-user application shortcuts in the desktop environment menus
kvm:
request-type: permission for the snap interface to be automatically connected when the snap is installed
reasoning: The snap cannot function without KVM capabilities
For the personal-files interface, I made sure to use the deepest fodler I could while staying reasonable. I do not expect any other files from any other apps to be in .local/share/applications/appack. Most apps (like office suites) will require this plug to be installed for the user. I think it would be reasonable to ask for auto-connection.
As for KVM, the core functionnality of the snap is based on emulating OSes and apps. Qemu will not start without KVM. Therefore I am requesting auto-connect as well.
Sorry or the late response, the whole team was out for past couple of weeks!
+1 (#voteFor) from my side, for autoconnecting kvm, as well as the personal-files interface, as .local/share/applications/appack is clearly owned by the snap.
Hello!
Given the provided context and the app’s functionality, this is also a +1(#voteFor) from me for auto-connecting kvm and the personal-files interface for write access to the specified file path for the appack snap. Thank you for your patience!
kvm interface looks reasonable considering the snap functionality.
personal-files interface is mostly used to maintain backwards compatibility with previous installations of the application (such as .deb). Given that this is a very fresh project I think it would be better to use the snap home directory rather than the real home directory. See https://snapcraft.io/docs/environment-variables#heading--home
How would it be possible to add desktop entries to the current user’s desktop environment at runtime without using the `personal-files` interface? I copied the Steam snap implementation for this feature.
I can dedicate time refactoring to use another interface, but I will need guidance.
It might be acceptable for well-known applications published by mature, well-known entities (still would need to be discussed in a case by case basis). As of today, I believe that appack doesn’t meet this criteria because of the following reasons:
The project seems to be very fresh, according to the upstream repository
The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.)
I could not find evidences that the project has a strong enough user base currently
Thus, considering these factors, -1 from me (#voteAgainst), and I would also ask other reviewers to reconsider their votes.
I know that .desktop files in $HOME/.local/share/applications can be a risk, but Snap apps can access the Desktop folder because it’s inside the $HOME folder. I did a small test, putting a .desktop file in the Desktop folder, but instead of starting a Snap app, it started a .sh file. The .sh file changed what was in the Exec= field to execute something else that wouldn’t use Snap’s confinement.
Basically, preventing access to the $HOME/.local/share/applications folder only makes it a little harder for someone who wants to do something bad, but it doesn’t completely prevent the problem.
It makes sense to prevent access to the $HOME/.local/share/applications folder by default to make life harder for malicious apps, but it doesn’t make much sense to fear that apps that are trusted or from trusted developers will access this folder.
Regarding game launchers that run native Linux games or games that run via Wine/Proton/UMU, they are an exception.
Even if the steam-support plug becomes available for this type of app, I imagine it would be a lot of work to create game launchers just to try to get the steam-support plug and then try to do something malicious.
Especially considering that the common practice in the community is to prefer launchers that are well-known, that have been around for a long time, like Heroic, Lutris, Faugus, Bottles, Minigalaxy, etc.
There is little to no community around it because… it’s not released yet and it’s not being approved on the Snap store.
I understand the security concerns, but in this case can you please reassure us, and say you are planning to engineer an API that will allow for proper desktop integration? This seems to be a fairly common issue with no proper solution yet.
Otherwise this would be the second time my plans to publish a Snap would go to waste because of sandbox or API limitations. I must say I am getting increasingly frustrated with the process, even though I am grateful for your world class professionalism and engineering.
In the meantine, like @Kyuyrii suggested, I will find time to refactor the code and copy the .desktop files on the desktop, eventually prompting the users to copy them manually in their .local/share/applications (which isn’t ideal).
I understand the security concerns, but in this case can you please reassure us, and say you are planning to engineer an API that will allow for proper desktop integration? This seems to be a fairly common issue with no proper solution yet.
Any operation of this type should be mediated by snapd, but I think it would be extremely hard to do it in a secure way. I’m not aware of any plans in this direction, but perhaps @pedronis can provide more information.
At this point, I think that launchers should either use classic confinement or not be distributed as snaps at all. Otherwise, this generates a false sense of security.
Otherwise this would be the second time my plans to publish a Snap would go to waste because of sandbox or API limitations. I must say I am getting increasingly frustrated with the process, even though I am grateful for your world class professionalism and engineering.
I’m really sorry about that.
In the meantine, like @Kyuyrii suggested, I will find time to refactor the code and copy the .desktop files on the desktop, eventually prompting the users to copy them manually in their .local/share/applications (which isn’t ideal).
If you plan to follow this path, I would not use ~/Desktop but a different directory under $HOME. I think we should possibly deny access to ~/Desktop in the default policy, in the same way we deny access to ~/bin, to be honest ( @pedronis ).
I understand that prompting the user to copy the .desktop files is not ideal from a usability perspective. However, from a security standpoint, I think it is not acceptable to allow snaps to plant .desktop files that will later run arbitrary code unconfined without making the user explicitly aware of it.
I’m sorry for all the inconveniences, I understand how frustrating it is to put effort into something that cannot be published.
In Nautilus, .desktop files are not opened; the information in the Exec= and Icon= fields is not used, and running as a program does not execute the .desktop command.
However, Nemo, the file manager for Cinnamon and also used in Ubuntu Budgie, displays the .desktop file in the same way it does when it’s on the desktop. And if I’m not mistaken, Nemo is also used in the Ubuntu Unity flavor.
Dolphin and PCManFM-Qt show the filename instead of what’s in the Name= field, but they use the icon, making it clear that it’s something that can be opened.
In short, even if this change occurs, it won’t significantly increase security in Ubuntu Budgie, Kubuntu, Lubuntu, Ubuntu Studio, Ubuntu Unity, Ubuntu Cinnamon, KDE Neon, etc…
Furthermore, the Desktop folder isn’t just for .desktop files, so it will likely worsen the experience for many users and make things much more confusing.
I imagine there’s simply nothing that can be done about the .desktop files created in the Desktop folder.
Continuing to block access to $HOME/.local/share/applications makes more sense because a malicious app could place a .desktop file with higher priority than the original .desktop file, which wouldn’t be easily noticed by the user, since the $HOME/.local/share/applications folder is rarely accessed and I don’t recall seeing the app menus differentiating between system .desktop files and those created by apps.
If an app can’t be published with personal-files because of security concerns, I have a hard time believing it will get accepted with classic confinement at all.
Besides, launchers are explicitely marked as Unsupported for classic confinement requests.
In this case I’ll just make a curl https://.. | bash installer until Snapd gets more mature.
Please feel free to discuss this topic here or elsewhere as I would love to use the correct tools when the time allows it.
I’m on Debian Sid with Gnome testing some things. If a .desktop file exists in $HOME/.local/share/applications trying to pretend to be another app, there’s no simple way to see which one is the original, in other words, which app is installed and which .desktop file was created in $HOME/.local/share/applications.
I imagine the ideal would be for the app menus of desktop environments to show which apps come from the $HOME/.local/share/applications folder.
That way it would probably be possible to add the option to hide them and even prevent them from launching.
