Hello!
I am the upstream developer of Tusk, an open-source Electron based Evernote desktop app. I am requesting classic confinement since the app needs to have access to any directory/file-system the user decides, in order to export notes as .pdf files, as well as, access to the system tmp directory for note printing on demand. Additionally, the app has the ability to launch the default system installed pdf viewer and text editor for note editing/viewing, if the user wants to do so. For the record, the snap is created by the electron-builder through travis-ci, along with all the other installers/packages, whenever a new version of Tusk is released. The snap has already been pushed to snapcraft and is under manual review pending status. Auto-building and publishing support through snapcraft’s building farm will be added really soon.
Thank you in advance for your time!
This doesn’t feel like it should need to be classic. The user would typically export PDFs to their home directory, would they not? That should be covered by the home interface. Why does printing need /tmp access? I can print from strictly confined applications which do not have that access.
Printing would need access to /run/cups/cups.sock, which at the moment is accessible with the cups-control interface. It doesn’t autoconnect though, since it can also reconfigure printers (with the right access).
Longer term, the desktop interface should gain print support through xdg-desktop-portal, but we’re not there yet.
There are edge cases where exporting to a cloud-based directory, which can be located outside the user’s home, can lead to unexpected app crushes thus providing the user with a bad experience.
While printing, the app uses the Electron API, under which a temporary PDF file is created at the system’s tmp directory, in order to be safely and securely removed by the system itself, before the initialization of the printing process. That could change but I would prefer to stay within the suggested API guidelines.
Last point that I forgot to mention, and I deeply apologize for, is that Electron needs access to the user’s ~/.config/Tusk directory in order to store cookies and cache data as well as to save user configuration/settings which are updated with read and write operations each time the user modifies an app setting/option. That could also change but it is something strongly recommended not to do in production.
These are the three main reasons, if all of them can be resolved under strict confinement I would be happy to withdraw my request at once : )
For the last point, confined snaps automatically rewrite the $HOME variable to a unique home directory for each snap. Assuming the ~ is expanded to $HOME (which is not always the case), this should be handled transparently.
What specific accesses are causing trouble? I would think that a cloud-based directory would be exposed via the ‘home’ interface or, perhaps, simply be handled by the ‘network’ plug.
FYI, the snap-specific /tmp directory will also be cleaned by the OS on reboot since it is actually a subdirectory in the system’s /tmp. Is this what you were concerned about or something else?
Snaps have their $HOME set to ~/snap/tusk/<revision> and your snap has full access to ~/snap/tusk/<revision>/.config/Tusk (or anything else you want in there). If your snap is trying to access ~/.config/Tusk when run under confinement, then your snap is not correctly evaluating the $HOME environment variable (it might, for example, be using getpwent()). The application should be adjusted to use $HOME instead.
