The Netron app allows users to open machine learning model files (or drag & drop them into the app) and visualizes these files. The app supports the removable-media interface. Auto-connect removable-media for netron for context.
Users are have been reporting permission errors when opening files from other specific locations: https://github.com/lutzroeder/netron/issues/504
Issue #1 files with ~/.xxx/file.model type locations fail to open
Request #1 Is it possible to auto-connect the personal-files interface which seems to be the suggested way to resolve this issue?
Issue #2 files assigned to different owners fail to open
Request #2 is there an interface to support loading of files from different owners and is it possible to auto-connect this interface as well?
Opening files from an arbitrary hidden (dot-prefixed) folder in the user’s home directory is not possible via personal-files - instead if there is a specific common location that is specific to the snap (such as ~/.cache/netron) then it would be possible to grant this via personal-files - but due to the presence of arbitrary sensitive things within the hidden folders inside $HOME (~/.gpg, ~/.ssh, etc) then it is not wise (or even possible in the current way the personal-files interfaces works) to grant a snap access to this kind of location.
For files owned by different users, there is the read: all attribute which can be used with the home interface - however I suspect that both of these use-cases would be quite infrequent - most users would be opening files owned by themselves inside non-hidden folders - and so the vast majority of use-cases should already be supported by the existing home and removable-media interfaces.
Is there a recommended way to handle these situations? Users can select such files in the file open dialog or using drag & drop which results in access denied errors and a bad user experience.
If the snap plugs the desktop interface and the user has the xdg-desktop-portal bits installed then they should be able to choose any file in the file picker and these should not be blocked by snapd to my knowledge. Unfortunately drag-and-drop does not support this as far as I know.
But again I wonder how common these use-cases are (ie to access something from a hidden directory etc). Can you give any info on how often users need to do this?
@lutzroeder ping,
Can you please provide the requested information? Thanks!
@lutzroeder ping,
This request cannot proceed without the requested information…
@lutzroeder - since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks
Hi Alex,
It happens a a times a day for this app. There is no exact telemetry to narrow down the specific scenario, only generic errors like “EACCES: permission denied” or “EPERM: operation not permitted” and the context users provided for the ticket linked above. Snap is not a priority, e.g. deprecating Snap support given added complexity of multipass and arm64 is also under consideration.
Can you please provide more details on these EACCES / EPERM errors? What files are trying to be opened in these cases? Is it reproducible? Also you could try using snappy-debug to diagnose these - https://snapcraft.io/docs/debug-snaps#heading--snappy-debug
