Can't access files in /tmp

[ofnuts]

I cannot open files in /tmp. The directory appears in the file selector but is empty. As far as I can tell I can access all other directories. I can save/export files to /tmp and re-open them, but this isn't the real /tmp in my system (and seems to be reinitialized when the application is closed/restarted). I would guess there is some /tmp in the flatpak that masks the true /tmp. Couldn't that one have a special name to avoid masking that very useful directory?

[Jehan]

Our manifest uses --filesystem=host which means access to all files. But it is highly possible indeed that flatpak still mount specific directories differently (actually I know it does). I guess /tmp is one such special folder.
Maybe adding a specific --filesystem=/tmp would do the deed.
But is it really needed? Personally I never use /tmp directly myself.

[TingPing]

Yes /tmp is private by default and host does not include it but manually doing /tmp works.

[Jehan]

Ok thanks @TingPing! Well I don't find this directly that useful for sharing when one has one's full home access (well I don't find it useful, but clearly @ofnuts does, so who am I to deny it?), but I don't see it as being a serious security issue either, anyway, right? So why not!
Let's just add access.

If someone (@TingPing?) thinks that's not advisable, just tell me why so that I can think further.

Done with commit:

commit bf7aff3 (HEAD -> master, origin/master, origin/HEAD)
Author: Jehan jehan@girinstud.io
Date: Wed May 2 01:06:11 2018 +0200

Issue #11: Can't access files in /tmp.

Fixes issue #11.

org.gimp.GIMP.json | 1 +
1 file changed, 1 insertion(+)

[TingPing]

but I don't see it as being a serious security issue either, anyway, right? So why not!

It is a security issue but this package already gave up on that yea.

[Jehan]

Well yeah obviously any file access is a security issue by definition.
Yet GIMP is a software made to edit files as a primary purpose. It doesn't make sense to not allow file access of any file which the user should have access to (and /tmp is indeed one such place historically). :-/

Maybe that's not what you meant though. If there is a more specific security issue for this specific directory, then it could be reconsidered.
Anyway it's just hard, I know I won't please everyone, whatever I decide. :-/

[TingPing]

@Jehan Well we can have the filesystem discussion after Gtk3 port =)

[ofnuts]

@Jehan /tmp is used by processes to share files. For instance, the "Spectacle" screencapture in KDE will save the file in /tmp before calling Gimp if I ask it to "Export to Gimp". My forum activity also makes me download plenty of pictures for quick checks and the self-cleaning nature of /tmp is handy.

While we are on the subject:

1. how do I know if fixes for flatpak issues are available (in other words how/when I can update my version)
2. I noticed that the Gimp download page for Linux is now considering flatpak as the standard delivery/install mechanism, so should flatpak problems be reported on bugzilla.gnome.org? And if so shouldn't there be a "flatpak" component?

[Jehan]

/tmp is used by processes to share files. For instance, the "Spectacle" screencapture in KDE will save the file in /tmp before calling Gimp if I ask it to "Export to Gimp".

Yes but it doesn't matter here. Either both software are in the flatpak and they share a /tmp/ (even though not the /tmp/ as the rest of the system), either they are not and anyway won't interact with each other (not entirely true though; they could, for instance through dbus, etc.).

how do I know if fixes for flatpak issues are available (in other words how/when I can update my version)

Just update whenever you can, and if there are fixes, the update will pull the rebuilt GIMP. If your distribution has built-in flatpak support, it may even propose you to update from time to time (together with other updates of the system).

I noticed that the Gimp download page for Linux is now considering flatpak as the standard delivery/install mechanism

Someone else made the remark that it is the recommended installation for Linux. It is not the case (not yet). On the download page, there is even this text clearly saying:

The flatpak build is very new and therefore may have shortcomings. It's very likely your Unix-like system distribution already comes with a GIMP package. It is the preferred method of installing GIMP, as the distribution maintainers take care of all the dependencies and bug fix updates. Nevertheless, note that many distros decide to pin a specific version of GIMP to their releases, whereas our flatpak will follow GIMP releases closely.

The flatpak technology is new, and GIMP in flatpak has several feature losses (that we know of already, I'm sure we may discover more as time goes). Some feature losses can probably be fixed on our side by tweaking the flatpak, but several are either limitations of the sandbox model, or implementations which will need to happen on flatpak side (as examples: using darktable/RawTherapee as raw plug-ins of GIMP doesn't work because of sandbox model; and midi device support is broken as well, there is a bug report about it, and I am not really optimist about a resolution soon).

So no, as it stands, flatpak is not the most recommended way. It may become some day. We'll have to see how things evolve. But currently, the only possible full-featured GIMP is still made by old-school packages.
Why the flatpak build is prominent on our download page is only because that's the only thing we can propose, since the recommended way is not maintained by us, by definition. It is maintained by distributions.

so should flatpak problems be reported on bugzilla.gnome.org? And if so shouldn't there be a "flatpak" component?

I wondered about this too. This would make sense. On the other hand, the flathub infrastructure currently forces us to have a github repository, which comes with its own bug tracker, etc. So if we were to duplicate all the report points, this becomes a bit messy (this being said, several people already reported bugs related to flatpak package on bugzilla, so…). Well in the very end, I don't really know!
I wished we could have just tracked our flatpak source in GIMP repo as everything else. This would be less of a mess.