GLib issue cannot open .jpg files

[ineuw]

Installed in Linux Mint Cinnamon 21.2, the files open in other image apps.

GLib.GException: Error opening file /media/wikimedia/art/illustrators of montmartre/IOM D056 Portrait of Mr Drumont.jpg: Permission denied
   at GLib.FileAdapter.Read(Cancellable cancellable)
   at Pinta.Core.GdkPixbufFormat.Import(IFile file, Window parent)
   at Pinta.Core.WorkspaceManager.OpenFile(IFile file, Window parent)

[Cameron White (cameronwhite91)]

Which version of Pinta are you using, and is this the flatpak or snap package (if so, this may be a sandboxing permission issue causing Pinta to be unable to open the file)

[ineuw (ineuw)]

I am using Pinta 2.1.1 installed with snap. I believe the problem may be Cinnamon, This happens when selecting Pinta as the "Open with" app from Nemo's context menu. But Pinta opens the document when selected from Pinta's Open file dialog.

[ineuw (ineuw)]

At this point, I could use your guidance. Should I report this to Linux Mint as well? Would it help?

[Cameron White (cameronwhite91)]

The open file dialog is likely different because it goes through the file chooser portal which handles sandboxing, but the "Open With" is just passing some command line arguments that Pinta tries to directly open as files.

I wonder if granting permissions to https://snapcraft.io/docs/removable-media-interface is needed, since I noticed the path is under /media
You could try something like 'sudo snap connect pinta:removable-media'

[ineuw (ineuw)]

Giving permissions resolved the issue. Thanks for the help and your contribution to my understanding.

[James Carroll (james-carroll)]

We'd be able to ask for a store override to automatically connect the removable-media interface. Pinta probably counts as an exception for it (as a media editor).

Would you think it'd be worth doing so Cameron? If so, I'll post on the snap forums and ask for permission.

Personally I'm a bit torn, since I'd prefer that some magic happened in the file manager that would actually work with the sandbox; in the ideal world /mnt and /media would only contain low sensitivity material but in the real world (e.g myself), it'd give access to e.g all the Windows OS dual booted on the machine, private keys and all.

But that's balanced on the fact Pinta has low potential to be exploited so I could easily imagine most people would prefer it "just worked", since in contrast to most other applications on the system, they already have that access.

[Cameron White (cameronwhite91)]

Yeah I think connecting that by default is probably the best for the user experience. I agree it'd be better if there was some sort of better sandboxing support for this (perhaps there is and I'm just not aware of it - Pinta just tries to open its command line arguments as regular file paths)

[James Carroll (james-carroll)]

There's some capability in the portals to check if any given snap/flatpak has access to a file, and if not, drop it in the sandboxed namespace the same way the file picker works. It's not something we'd be able to do on our end though, it'd require the file manager to assess if the target application is confined, whether the mediation is needed, and actually perform it. From Pinta's perspective, it'd just be as if everything was in `/run` by coincidence and in theory wouldn't require any changes on the app end.

Unfortunately, I don't think it's yet a thing in any DE I'm aware about.

I've put a request in the forums to get the automatic connection going. There's a week waiting period to collect votes and if successful, I'll need to push a new revision out to encourage the older clients to download the new asserions to fully trigger it, otherwise it'd only be new installations that would have recieved the new instructions from the store.

https://forum.snapcraft.io/t/request-for-automatic-removable-media-connection-for-pinta/36178

[Cameron White (cameronwhite91)]

Sounds good, thanks for submitting that!

[James Carroll (james-carroll)]

A new snap revision is rolling out to update all the existing installations to have removable-media connected by default now.

This is part of the signature generated & signed by the store, so doesn't apply to development builds or unverified builds; i.e, whenever `--dangerous` is a parameter to the install. Every now and then someone might try install offline without using the accompanying signature which would be the main reason this might not connect automatically anymore.

[Cameron White (cameronwhite91)]

Sounds good, thanks James!