GIMP 2.10.2: Open Location fails: volume doesn't implement mount

1

Opening an image from a HTTPS location fails with error:

volume doesn't implement mount

Here’s a screenshot when I tried to open an image:

The error is the same for HTTP locations. The flatpak version doesn’t have this issue, so it’s not a GIMP generic issue.

Is there something that needs to be configured to make this work ?

I’m running GIMP 2.10.2 on Xubuntu 18.04.

I’ve only installed snap GIMP and VLC, so I’m still not quite sure where to report issues. I reported the issue on snapcrafters/gimp, but I get the impression it wasn’t the correct place.

2

It probably doesn’t have the gvfs backends needed for this. If it does, do you have any security denials in journalctl (sudo journalctl | grep audit:) at the time of the error?

3

I have all the gvfs-* packages installed:

ii  gvfs:amd64      1.36.1-0ubuntu1 amd64        userspace virtual filesystem - GIO module
ii  gvfs-backends   1.36.1-0ubuntu1 amd64        userspace virtual filesystem - backends
ii  gvfs-common     1.36.1-0ubuntu1 all          userspace virtual filesystem - common data files
ii  gvfs-daemons    1.36.1-0ubuntu1 amd64        userspace virtual filesystem - servers
ii  gvfs-fuse       1.36.1-0ubuntu1 amd64        userspace virtual filesystem - fuse server
ii  gvfs-libs:amd64 1.36.1-0ubuntu1 amd64        userspace virtual filesystem - private libraries

but I suppose snap GIMP doesn’t use them, does it ? As you can see, I’m a rookie as regards snap applications, so my questions are bound to be very ignorant. How do I make the gvfs backends available to the snap GIMP ?

I had uninstalled snap gimp, so I installed it again and tried to open this image. I collected all journalctl audit messages with:

jc -t audit -S '2018-06-13 19:00' >audit.log

And pasted audit.log.

I can’t understand why there are so many DENIED messages, and I couldn’t find reference to the Open Location operation.

In case it throws any light on these errors, this is how I installed GIMP:

snap install gimp --edge

It occurred to me that the issue might be with the edge channel version, so I uninstalled gimp from the edge channel, reinstalled it from the stable channel, and tried to open this image, but the error was exactly the same.

Reading this issue, where someone couldn’t open a local file with GIMP, it occurred to me: shouldn’t the GIMP snap have access to the network plug in order to open images using http/https transport ? But I can’t see a network slot in the GIMP snap:

paulo:~/tmp$ snap interfaces gimp
Slot             Plug
:desktop         gimp,vlc
:desktop-legacy  gimp,vlc
:gsettings       gimp
:home            gimp,vlc
:opengl          gimp,vlc
:unity7          gimp,vlc
:wayland         gimp
:x11             gimp,vlc
-                gimp:cups-control
-                gimp:removable-media

Shouldn’t it have one ? Perhaps (most likely !) I got this plug/slot architecture completely wrong.

I’m really at a loss: is there something else I should have and can do to solve this issue ?

Thanks for replying, @jdstrand !

5

It will need network access to open from the internet, yes. Are there security denials (sudo journalctl | grep audit: at the time of the denial)?

I’m not an expert on gvfs, but can say that just having the packages staged in the snap isn’t enough-- there are environment variables that need to be set for all the backends to be found and the desktop-launch script does not currently seem to set them.

6

I’ve just repeated the Open Location operation and collected all audit messages from systemd journal. This message is repeated many times:

jun 14 10:32:32 monk audit[8744]: SECCOMP auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=8744 comm="gimp" exe="/snap/gimp/41/usr/bin/gimp-2.10" sig=0 arch=c000003e syscall=93 compat=0 ip=0x7fea9d777337 code=0x50000

but I suspect it’s not related to the Open Location attempt, since they also appear when I quit GIMP.

Do you know how I can check whether they are indeed staged ?

Do you know what is the appropriate place to report this ?

Thanks, a lot!, for not giving up on this issue, @jdstrand !

7

Check out ubuntu/snapcraft-desktop-helpers: Various launchers for snapcraft wiki parts for issues regarding to the desktop-launch script (probably belongs to them).

8

Thank you so much for the pointer, @Lin-Buo-Ren ! I’ll report this issue over there.

EDIT: Issue reported.

1 Like
9

FYI, syscall 93 is chown on amd64. It seems like it is doing an unconditional chown on a file and not checking the return code so it continues like normal. This is not unusual for an application to do and can an all likelihood be safely ignored.

10

I’m learning quite a lot here, thanks for that ! I didn’t know syscalls were numbered. Found a table here after your pointer.

11

Weird thing: I ran gimp --verbose, tried Open Location and collected all output (it’s pasted here): there’s no message whatsoever associated with Open Location.

12

Each architecture is going to be different and it’ll also depend if you are using an 32 bit app on a 64 bit machine. I suggest ‘sudo apt-get install seccomp’ then you can use scmp_sys_resolver. Run this on a system that is the same architecture as where you see the denial.

You can also ‘snap install snappy-debug’ and run sudo snappy-debug.security scanlog and it’ll do all this for you.

13

Great tips, @jdstrand ! I’ve just installed both, and that audit message is scanned and expanded to:

= Seccomp =
Time: Jun 14 13:36:16
Log: auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=4299 comm="gimp" exe="/snap/gimp/41/usr/bin/gimp-2.10" sig=0 arch=c000003e 93(fchown) compat=0 ip=0x7fc25a071337 code=0x50000
Syscall: fchown
Suggestions:
* don't copy ownership of files (eg, use 'cp -r --preserve=mode' instead of 'cp -a')
* try the snapcraft preload plugin: https://github.com/sergiusens/snapcraft-preload
* adjust program to not use 'fchown'

Really useful ! Although inocuous, I guess this might also be reported to whoever builds the GIMP snaps.

1 Like