Cannot open PDF attachment with Thunderbird

Hello,

I’m using snap on those versions:

snap    2.39
snapd   2.39
series  16
ubuntu  18.04
kernel  4.15.0-51-generic

I’ve installed Thunderbird from the store

name:      thunderbird
summary:   Mozilla Thunderbird email application
publisher: Ken VanDine
license:   unset
description: |
  Thunderbird is a free email application that’s easy to set up and customize - and it’s loaded with
  great features!
commands:
  - thunderbird
snap-id:      k1Ml1O9GzSO2QftV0ZlWSbUfQ78nN460
tracking:     beta
refresh-date: 2018-11-27
channels:
  stable:    –                            
  candidate: –                            
  beta:      –                            
  edge:      60.6.1 2019-04-09 (33) 100MB -
installed:   60.3.0            (29) 145MB -

I’ve also installed evince as snap package, but seems to be impossible to open a PDF attachment directly from thunderbird, I have to save it and then open from nautilus manually.

If you need more details let me know, thanks in advance.

Hi!

Same problem here!

Did you manage to find a solution?
Thanks

Can you comment on if there a security denials in the journalctl logs at the time of the denial (if so, what are they)? If so it may be that thunderbird is not using xdg-open to open the file.

That said, I suspect the actual problem is, like firefox, that the snap is saving the file to ‘/tmp’ within the context of the snap which is not ‘/tmp’ on the host so the pdf viewer is given the wrong path.

@zyga-snapd, @jamesh and @kenvandine - in the case of xdg-open, I was thinking there might be something we can do here since we control xdg-open and it could in theory know the correct path on the host. It seems possible that xdg-open could determine and pass the correct path for files in /tmp to the handler which could be sufficient for non-snaps like evince at least. The problem these days is that /tmp/snap.<snap name> is root:root 700 so /tmp/snap.<snap name>/tmp/... is not permitted by DAC. Since this naive lookup won’t work with DAC, it’s conceivable we could instead expose the file somewhere that is allowed (eg via a portals-like approach) and have xdg-open pass that path. I’ve not looked at this approach but wanted to pass the idea along.

Hi,
It looks like there is a security denial in the journalctl indeed. Here is the paste:

juil. 10 13:11:48 paul-MS-7751 kernel: audit: type=1400 audit(1562757108.400:693): apparmor="DENIED" operation="capable" profile="snap.thunderbird.thunderbird" pid=32473 comm="thunderbird-bin" capabil
juil. 10 13:11:59 paul-MS-7751 sudo[32484]:     paul : TTY=pts/5 ; PWD=/home/paul/Bureau ; USER=root ; COMMAND=/usr/bin/emacs launch_thunderbird.sh
juil. 10 13:11:59 paul-MS-7751 sudo[32484]: pam_unix(sudo:session): session opened for user root by (uid=0)
juil. 10 13:12:08 paul-MS-7751 sudo[32484]: pam_unix(sudo:session): session closed for user root
juil. 10 13:12:13 paul-MS-7751 audit[32494]: AVC apparmor="DENIED" operation="open" profile="snap.thunderbird.thunderbird" name="/proc/32494/net/arp" pid=32494 comm=4C696E6B204D6F6E69746F72 requested_
juil. 10 13:12:13 paul-MS-7751 kernel: audit: type=1400 audit(1562757133.600:694): apparmor="DENIED" operation="open" profile="snap.thunderbird.thunderbird" name="/proc/32494/net/arp" pid=32494 comm=4
juil. 10 13:12:13 paul-MS-7751 dbus-daemon[1468]: apparmor="DENIED" operation="dbus_bind"  bus="session" name="org.mozilla.thunderbird.ZGVmYXVsdA__" mask="bind" pid=32494 label="snap.thunderbird.thund
juil. 10 13:12:22 paul-MS-7751 audit[32494]: AVC apparmor="DENIED" operation="open" profile="snap.thunderbird.thunderbird" name="/snap/libreoffice/134/usr/share/icons/gnome/256x256/apps/libreoffice6.2
juil. 10 13:12:22 paul-MS-7751 kernel: audit: type=1400 audit(1562757142.232:695): apparmor="DENIED" operation="open" profile="snap.thunderbird.thunderbird" name="/snap/libreoffice/134/usr/share/icons
juil. 10 13:12:22 paul-MS-7751 audit[32494]: AVC apparmor="DENIED" operation="open" profile="snap.thunderbird.thunderbird" name="/snap/libreoffice/134/usr/share/icons/gnome/256x256/apps/libreoffice6.2
juil. 10 13:12:22 paul-MS-7751 kernel: audit: type=1400 audit(1562757142.256:696): apparmor="DENIED" operation="open" profile="snap.thunderbird.thunderbird" name="/snap/libreoffice/134/usr/share/icons
juil. 10 13:12:23 paul-MS-7751 audit[32494]: AVC apparmor="DENIED" operation="open" profile="snap.thunderbird.thunderbird" name="/snap/libreoffice/134/usr/share/icons/gnome/256x256/apps/libreoffice6.2
juil. 10 13:12:23 paul-MS-7751 kernel: audit: type=1400 audit(1562757143.424:697): apparmor="DENIED" operation="open" profile="snap.thunderbird.thunderbird" name="/snap/libreoffice/134/usr/share/icons
juil. 10 13:12:24 paul-MS-7751 audit[32494]: AVC apparmor="DENIED" operation="open" profile="snap.thunderbird.thunderbird" name="/snap/libreoffice/134/usr/share/icons/gnome/256x256/apps/libreoffice6.2
juil. 10 13:12:24 paul-MS-7751 kernel: audit: type=1400 audit(1562757144.740:698): apparmor="DENIED" operation="open" profile="snap.thunderbird.thunderbird" name="/snap/libreoffice/134/usr/share/icons
juil. 10 13:12:40 paul-MS-7751 dbus-daemon[1468]: [session uid=1000 pid=1468] Activating service name='org.gnome.Nautilus' requested by ':1.21' (uid=1000 pid=1607 comm="/usr/bin/gnome-shell " label="u
juil. 10 13:12:40 paul-MS-7751 dbus-daemon[1468]: [session uid=1000 pid=1468] Successfully activated service 'org.gnome.Nautilus'
juil. 10 13:12:40 paul-MS-7751 org.gnome.Nautilus[1468]: Initializing nautilus-dropbox 2015.10.28
juil. 10 13:12:41 paul-MS-7751 dbus-daemon[761]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.488' (uid=1000
juil. 10 13:12:41 paul-MS-7751 systemd[1]: Starting Hostname Service...
juil. 10 13:12:41 paul-MS-7751 dbus-daemon[761]: [system] Successfully activated service 'org.freedesktop.hostname1'
juil. 10 13:12:41 paul-MS-7751 systemd[1]: Started Hostname Service.
juil. 10 13:12:41 paul-MS-7751 nautilus[32704]: Called "net usershare info" but it failed: L’exécution du processus fils « net » a échoué (No such file or directory)

Does this help?

I tried this script I saw elsewhere with no success:

#!/bin/sh
export TMP=/tmp
nohup thunderbird &

I also noticed that all apps have an error icon when clicking on “open with”

thunderbird_bug

Let me know if you need more details and thanks for your help

Those security policy denials were truncated, but it seems that thunderbird is trying to launch the handler directly rather than the snapd-provided xdg-open. That would be a bug in the thunderbird snap.

Unfortunately things aren’t quite as simple as you make out here. The xdg-open tool is a command that implements the XDG mime apps spec. Most desktop applications include a native implementation of the spec (through GTK or Qt) rather than shelling out to that tool.

So instead they will look for .desktop files in the appropriate search paths that claim to support the mime type of the file it is trying to open. The reason the xdg-open proxy gets called for HTTP URIs is that the core snap provides a /usr/share/applications/xdg-open.desktop file that claims to support x-scheme-handler/http.

In the particular case of this Thunderbird snap, it plugs the browser-support interface which happens to grant access to desktop files in /var/lib/snapd/desktop/applications (which will be on the search path). So if some other snap on the system claims to support the mime type, it will try to invoke that application directly. Judging by the screenshots earlier in this thread, this includes the LibreOffice snap.

We worked around all of this in the Firefox snap by shipping a mimeapps.list file that sets xdg-open.desktop as the default application for a large number of mime types. I’d prefer not to make promulgate this hack further or try to integrate it into the core snap though, since it interferes with the xdg-desktop-portal method of opening associated applications, which triggers if no other handler is found.

It might be worth killing that /var/lib/snapd/desktop/applications AppArmor rule in browser-support though: I can’t think of a situation where it is actually useful.

@jamesh: it sounds like you are saying that removing this might make things work for snaps that plugs browser-support?

Ah, and is it possible to get this mimeapps and use it for thunderbird?

Edit: it looks like I can’t post more than 3 times in the same topic.
Anyway, I’m not sure I understand what is said here…
In the end, @jdstrand @jamesh is it possible for the average user to fix this problem without waiting for an updated packages?

Many thanks again for your help

It would prevent Thunderbird from trying to launch LibreOffice Draw directly in this case. It wouldn’t cause it to call xdg-open instead though.

Understood. While I understand that you don’t want the mimeapp.list file hack in core, perhaps it makes sense for thunderbird until something better is available?

I’ve added this to the list for the next batch of updates. I’ll ping you in the PR when I propose it.

It probably would be worth replicating the mimeapps.list hack in this snap, yes.

Note that the snap only has releases published in edge, and is up to revision 35. So I’m not sure Ken intended it to be ready for general use.

The thunderbird snap was really only meant to be a POC and has never been deemed stable enough to recommend use. We’ve had some discussions with upstream, but no concrete plans on them supporting the snap yet.

Looking at this further, /var/lib/snapd/desktop/applications is part of browser-support, desktop-legacy and unity7. From my understanding of the request, a snap that plugs any these interfaces cannot do anything with what it finds in /var/lib/snapd/desktop/applications and so denying the access is sensible. There is a /var/lib/snapd/desktop/applications/mimeinfo.cache that maps desktop files in /var/lib/snapd/desktop/applications to mimetypes, but this is for things other than the snap to use.

From this topic, snaps should always use xdg-open from snapd (and may optionally ship a mimeapps.list so that xdg-open will open other mime types so long as the url matches one of the allowedUrlSchemes in laucher.go. This should be improved so snaps don’t have to do that but that is separate from this topic).

@jamesh - based on the above, is there any legitimate use case for a snap to be able to read /var/lib/snapd/desktop/applications or any of its files? What about /usr/share/applications? /etc/gnome/defaults.list? /etc/xdg/<things>/defaults.list (eg, lubuntu)?

Noticed that /etc/mailcap is also in browser-support. That would ideally be removed and solved with a layout, but I think that one may be risky to remove.

I’m a bit leery of removing any of these accesses since I don’t want to break applications (ie, they may fail gracefully when working with something they’ve found in /var/lib/snapd/desktop/applications, etc, but may not if the read on the directory is denied).

I noticed that desktop-legacy has:

# This leaks the names of snaps with desktop files
/var/lib/snapd/desktop/applications/ r,
/var/lib/snapd/desktop/applications/mimeinfo.cache r,
# parallel-installs: this leaks read access to desktop files owned by keyed
# instances of @{SNAP_NAME} to @{SNAP_NAME} snap
/var/lib/snapd/desktop/applications/@{SNAP_INSTANCE_NAME}_*.desktop r,

which suggests that an application may want to legitimately read its own desktop file. This was introduced in c9ddbe94c75137c7589847f0a20d6138d6d7c797 I believe to support BAMF_DESKTOP_FILE_HINT. As such, desktop-legacy should not be updated as it doesn’t allow reading all files, just the snaps. The unity7 interface allows the same so it should also not be updated.

Ok, looking at this even more, I see that browser-support only allows this with ‘allow-sandbox: true’ which means that only a few snaps are affected. I’ve decided to not add an explicit deny for now, but add additional text:

# Snaps should be using xdg-open from the runtime instead of reading these
# files directly since the snap is unable to do anything with these files
# but these accesses have been allowed for a long time and remain so as not
# to break existing snaps. These could be changed to explicit deny rules,
# but that provides a worse debugging experience. Combined, the risks
# outweigh the benefits of closing this information leak for the small
# number of snaps allowed to use allow-sandbox: true. Reference:
# https://forum.snapcraft.io/t/cannot-open-pdf-attachment-with-thunderbird/11845

We definitely need /usr/share/applications. In both the core and core18 snaps, we ship the files xdg-open.desktop and mimeapps.list in order to get applications using the XDG mime spec to call our xdg-open proxy for http/https/mailto URLs.

I don’t believe there is any need for /var/lib/snapd/desktop/applications. As mentioned in other threads, I suspect this was originally added after observing denials in the audit log for confined applications: that does not mean that those apps can do anything useful with the contents. As we include /var/lib/snapd/desktop in XDG_DATA_DIRS and don’t do anything to try and remove it when launching snap applications, it isn’t surprising that they would attempt to read that path. So ideally we’d refuse access to all of /var/lib/snapd/desktop, and silence any audit messages.

I don’t think there is anything confined apps can do with the various defaults.list files in /etc either. As with the applications directories, conformant apps will attempt to read these paths but won’t get any useful data from them. It’s less of an information leak, since these are generally static files for each distro release. It’s probably safe to deny access and silence audit messages here too.

@jdstrand: following up on this, we ran into problems with this when testing its xdg-desktop-portal support. I filed bug #1868051 to help track this.

When we set GTK_USE_PORTAL=1, Firefox shows only a single option (“System Handler”) to open files and custom URI schemes. This ends up calling the GIO’s g_app_info_launch_default_for_uri API, which does the following:

  1. If there is a .desktop file available that can handle the content type (for local files) or URI scheme, invoke it directly.
  2. If there are no matches, call out to xdg-desktop-portal’s OpenURI API.

When the contents of /var/lib/snapd/desktop/applications is readable, Firefox will attempt to invoke those applications directly. This will of course fail because strictly confined apps can’t invoke other snap apps directly.

We noticed this problem when I was able to have Firefox launch LibreOffice to open a .docx file but Ken wasn’t. The difference between our systems was that Ken had the snap version of LibreOffice installed and I didn’t.

You said you didn’t want to risk breaking apps that might need to read those desktop files for some reason. It’s still not clear whether any such apps exist. Browsers might opportunistically access those desktop files if they are readable (by virtue of /var/lib/snapd/desktop being in $XDG_DATA_DIRS), but I haven’t seen any evidence of them failing if they can’t read them.

After discussing with @kenvandine, I commented in the bug and provided https://github.com/snapcore/snapd/pull/8301 for you to look at. Please see the bug as the PR implements one of 5 options I outlined.