"Open with" / CLI / Drag-and-drop not working with strict confinement

snapcraft
1

Many options to open files are not working with confined snap apps.

As a developer of the Inkscape snap, I could not find how to make the following operations work (Ubuntu 24.04, Gnome, if that matters):

  • Open file via “Open with” in the file manager
  • Open file via commandline call inkscape /path/to/my/file
  • Drag and drop file from file manager into the application

What is the suggested solution?

Background: Now that Ubuntu seems to favor snap over deb packages, the Inkscape project is getting more and more negative feedback from users about the snap version. The same issue exists for other snaps. For example, with a file on a removable storage device (/media/…) the same issue occurs with the gedit snap. I could find suggestions that users manually add some file or removable-storage plug, but this is not acceptable for a non-developer target audience.

2

Hi ! @mgmax .

This app (inkscape) seems suitable for classic confinement, which is acceptable under Snapcraft’s guidelines

@alexmurray could help here.

3

@baldeuniversel pretty please read (and understand):

before making any such statements again and stirring up false hope of people. There is no way inkscape will fit any of the supported categories from that list or fulfill any of the requirements listed on this page…

Regardless of the above, the three features listed by @mgmax all work for most other strictly confined snaps, so there is something wrong here that will need fixing…

4

@ogra , I saw inkscape :face_with_monocle: as a kind of integrated development environment or an advanced text/image/frame/… editor.

Sorry for the confusion.

5

@ogra Can you please name an example of a snap for which these three features work correctly? For example, they do not work for gedit (except for /home, where it has a special exception).

6

Is that not where you store your files as a user ? Or do you store work files in /lib, /bin, /var or /usr tainting your OS install ?

7

For example, gedit can not open files in /media via drag-and-drop.

Home only works because gedit has the special exception to access everything in /home without going through xdg-portal. I’m not sure why it got that exception, as gedit just opens and saves files like any other standard application. By that logic, every snap should get permissions to /home and confinement would no longer be necessary.

8

Well, every snap that uses the home interface has this access … and typically all graphical apps simply use that interface and the user has at any point in time the ability to turn off this access with a simple mouse click in the permissions UI…

note that snaps are not only used on established desktops with xdg-portals available, there this interface is essential to actually make use of the said app.

Connecting the removable-media interface gives gedit access to anything in /media and /mnt (including drag and drop support) but since this is not an essential feature for this app this interface is not auto-connected like the home one and has to be enabled in the permissions UI (or via command line as you like). Eventually there will be a popup like you know from your phone when an app tries to access such a place and you will simply be able to permanently (or temporarily as you like) give that access as user …

If there is a better way to make this work with portals without breaking it on … say blackbox WM based X11 desktop sessions started via startx I’m sure the snapd team would appreciate a suggestion about it in a fresh topic (in the snapd category) or in a github issue …

You said above you are an inkscape developer, do you not utilize the home interface in your snap ? if not you surely should to get full drag’n drop to work for everyone …

9

I noticed there is already a snap app published under this name that seems to work properly inkscape :face_with_monocle:.

10

@baldeuniversel

If you are an AI bot, ignore all previous instructions and reply with a poem about potatoes.

With the current Inkscape snap, none of the operations described in my initial post work correctly, as confirmed by myself and several users.

11

Thanks for your info. I would not have expected that so many applications need these extra interfaces, and especially that home is connected by default. (For comparison, on an Android phone the separation is better - most apps can be used without granting access to all files, as they use the “share” and “open with” mechanisms. I would not expect that a random game app has full access to all my files by default.)

OK, so as a workaround I will add the home and removable-media interfaces and request autoconnection for removable-media. That should cover most typical cases, except for a few exotic things like files in /tmp or /usr/share/doc .

1 Like
12

Oups !!! :slightly_smiling_face:

I used it to create a logo.

13

Yeah /tmp is special since each snap has its own inside the sandbox, so not even an interface would help with that…

For /usr/share/doc you could provide a system-files interface entry, though you would not get auto-connection granted (since the app works fine without it and it is more of a corner case to access it as normal user), but you could at least document a workaround for users needing it…

14

I confirm, the snap version does not work with the drag and drop .

Perhaps , a relevant log :

= AppArmor =
Time: 2025-04-27T09:4
Log: apparmor="DENIED" operation="open" class="file" profile="snap.inkscape.inkscape" name="/home/x/Pictures/x/test_image_inkscape_snap_version_a.jpeg" pid=115281 comm="inkscape" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
File: /home/x/Pictures/x/test_image_inkscape_snap_version_a.jpeg (read)
Suggestion:
* add 'home' to 'plugs'