Anki 26.09.2 installer can make /usr/share/mime unreadable with restrictive umask

This appears to be the same underlying problem reported previously but closed without a solution.

I have encountered what appears to be the same problem again with Anki 26.09.2 on Debian.

My shell uses a restrictive umask. After running the supplied Anki install script with sudo, I found two permission problems:

  1. Files installed under /usr/local/share/anki were readable only by root. I had already worked around this with:
chmod -R a+rX /usr/local/share/anki

  1. More seriously, files under the system-wide /usr/share/mime hierarchy had also become readable only by root.

The latter caused GTK applications invoked from Anki to fail. In Anki, selecting File → Import caused an immediate abort:

Gtk-WARNING **: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.

Gtk:ERROR:...: Failed to load
/usr/share/icons/Adwaita/scalable/status/image-missing.svg:
Unrecognized image file format

I initially checked and rebuilt the GDK Pixbuf loader cache and reinstalled the relevant Debian packages (libgdk-pixbuf, librsvg, etc.), with no effect. LD_DEBUG=libs showed that Anki was loading the normal Debian GTK/GDK Pixbuf/GLib libraries.

The problem disappeared immediately after restoring normal read/search permissions under /usr/share/mime.

So the apparent SVG/GDK Pixbuf error was actually caused by the MIME database being unreadable.

It appears that the installer, or xdg-mime / update-mime-database invoked by it, is inheriting a restrictive umask from the installation environment. Running the installer with an explicit system-install umask avoids the problem:

sudo sh -c 'umask 022; exec ./install.sh'

Even if the underlying behavior of update-mime-database is considered an upstream/distribution issue, I think the Anki installer should protect against it. A system-wide application installer should not be able to make /usr/share/mime inaccessible to ordinary users merely because the invoking user has umask 077.

Setting umask 022 near the beginning of the privileged Linux installation script would appear to be a simple defensive fix.

The same issue also explains why files copied into /usr/local/share/anki can otherwise end up root-readable only.

Where was it reported?

The links are not possible to enter, so remove the space after https to get there:

Logged here: Linux installer can make /usr/share/mime unreadable with restrictive umask · Issue #5636 · ankitects/anki · GitHub

Contributions are welcome.