====== Negenerování náhledů souborů v nautilus ======

  * několik dní zpět mi přestalo fungovat generování náhledů na sobubory.. takové ty náhledy na fotky, videa, atd
  * určitě to fungovalo 9.9.2017, protože z toho dne náhledy mám... později už nevím
  * dnes je 23.10, bylo provedeno několik aktualizaci... nevím která to mohla způsobit
  * zkoušel jsem založit nový systémový účet, abych vyloučil vliv mého nastavení na funkci. Chovalo se to stejně.

  * náhledy se ukládají do
    * ''~/.cache/thumbnails/fail/''
    * ''.thumbnails'' - asi dříve
  * pokud selže generování náhledu, tak se vytvoří soubor v podsložce fail. Je tam název programů, který se o generování pokoušel. Například ''~/.cache/thumbnails/fail/gnome-thumbnail-factory''. Více [[https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#FAILURES|zde]]
  * do obrázku se prý vkládají další [[https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#ADDINFOS|meta informace]]
  * gnome-thumbnail-factory je knihovna, volá thumbnails, viz description [[https://developer.gnome.org/gnome-desktop3/stable/GnomeDesktopThumbnailFactory.html|zde]]


===== Pokusy =====

  * vytvořil jsem [[troubleshooting:wrapper_cpp|wrapper]] pro binárku gdk thumbnailer
    * ''/usr/share/thumbnailers/gdk-pixbuf-thumbnailer.thumbnailer''
    * jestli bude vůbec zavolán a co dostane na vstup
    * pak bych mohl debugovat ten program.... který selhal
    * binárka se vůbec nezavolala při přístupu na fotky v nautilus (ani po vymazání cache)
    * přitom v mime je minimálně ''image/jpeg''

  * vytvořit si vlastní program, co používá gnome-thumbnail-factory
    * tím bych mohl vyzkoušet, zda to funguje vůbec :D
    * https://tecnocode.co.uk/2013/10/21/writing-a-gnome-thumbnailer/
    * našel jsem krásný [[https://ubuntuforums.org/showthread.php?t=779628|python sample]] kód, bohužel mi ale chybí závislosti (našel jsem jen python-gnome2 balíček)
    * co to vytáhnout ze zdrojáků nautilus?
      * musel jsem doinstalovat: 
        * ''libgnome-autoar-0-dev, libgail-3-dev, libgnome-desktop-3-dev, libgtk-3-dev, libtracker-sparql-2.0-dev, gobject-introspection''
      * zasekl jsem se na závislosti, která vůbec nevím co je :D

==== Vlastní program ====

  * bude to takový mix ... přepsání toho python sample do c++ po vzoru nautilus :D :D

<code makefile>
LIBS = $(shell pkg-config gnome-desktop-3.0 --libs) $(shell pkg-config gnome-vfs-2.0 --libs)
INCL = $(shell pkg-config gnome-desktop-3.0 --cflags) $(shell pkg-config gnome-vfs-2.0 --cflags)
CXXFLAGS = -O2 -g -Wall $(INCL) -DGNOME_DESKTOP_USE_UNSTABLE_API

OBJS = thumb-sampl3.o
TARGET = thumb-sampl3

$(TARGET): $(OBJS)
	$(CXX) -o $(TARGET) $(OBJS) $(LIBS)

all: $(TARGET)

clean:
	rm -f $(OBJS) $(TARGET)
</code>

<code cpp>
#include <iostream>
#include <ctime>
#include <sys/stat.h>
#include <libgnome-desktop/gnome-desktop-thumbnail.h>
#include <libgnomevfs/gnome-vfs-mime.h>

using namespace std;

int main(int argc, char **argv) {

  GnomeDesktopThumbnailFactory *thumbnail_factory;
  char *fpath;
  char *uri;
  time_t mtime;
  const char *mime_type;

  if (argc!=2) {
	  cerr << "No input file" << endl;
	  return 1;
  }

  fpath = argv[1];
  cerr << "filepath: " << fpath << endl;

  thumbnail_factory = gnome_desktop_thumbnail_factory_new (GNOME_DESKTOP_THUMBNAIL_SIZE_LARGE);

  if (!thumbnail_factory) {
    cerr << "cannot initialize" << endl;
    return 1;
  }

  cerr << "initialized with GNOME_DESKTOP_THUMBNAIL_SIZE_LARGE set to: ";
  cerr << GNOME_DESKTOP_THUMBNAIL_SIZE_LARGE << endl;

  GFile *loc;
  loc = g_file_new_for_path(fpath);
  uri = g_file_get_uri (loc);
  cerr << "uri: " << uri << endl;

  mime_type = gnome_vfs_mime_type_from_name(fpath);
  cerr << "mime_type: " << mime_type << endl;

  struct stat finfo;
  if (stat(fpath, &finfo)==0) {
	  mtime = finfo.st_mtim.tv_sec;
  } else {
	  cerr << "cannot get mtime of file" << endl;
	  return 1;
  }

  cerr << "mtime: " << mtime << endl;

  gboolean res;
  res = gnome_desktop_thumbnail_factory_can_thumbnail (thumbnail_factory,
                                                       uri,
                                                       mime_type,
                                                       mtime);
  cerr << "can thumbnail res: " << res << endl;

  GdkPixbuf *pixbuf;
  pixbuf = gnome_desktop_thumbnail_factory_generate_thumbnail (thumbnail_factory,
                                                               uri,
                                                               mime_type);

  cerr << "generated pixbuf??: " << (!pixbuf==NULL) << endl;

  if (pixbuf) {

    gnome_desktop_thumbnail_factory_save_thumbnail (thumbnail_factory,
                                                    pixbuf,
                                                    uri,
                                                    mtime);
    cerr << "after save_thumbnail" << endl;
    g_object_unref (pixbuf);

  } else {

    //gnome_desktop_thumbnail_factory_create_failed_thumbnail (thumbnail_factory,
    //                                                         uri,
    //                                                         mtime);
    //cerr << "after create_failed_thumbnail" << endl;

	cerr << "calling create_failed_thumbnail skipped" << endl;
  }

  //g_free (mime_type);
  g_free (uri);

}
</code>

==== Zjištění z vlastního programu ====

  * z prostého spuštění programu jsem nic nezjistil

<code>
./thumb-sampl3 /home/djbuldog/Pictures/Snímek\ z\ 2014-11-18\ 20\:27\:27.png 
filepath: /home/djbuldog/Pictures/Snímek z 2014-11-18 20:27:27.png
initialized with GNOME_DESKTOP_THUMBNAIL_SIZE_LARGE set to: 1
uri: file:///home/djbuldog/Pictures/Sn%C3%ADmek%20z%202014-11-18%2020:27:27.png
mime_type: image/png
mtime: 1416338848
can thumbnail res: 1
generated pixbuf??: 0
calling create_failed_thumbnail skipped
</code>

  * spuštění strace mi taky moc neřeklo
  * spuštění programu na virtuálním debian fungovalo a náhled vytvořilo
  * z porovnání strace jsem zjistil že:
    * virtuální debian soubor s png obrázkem otevřel a následně načítal knihovnu ''libpixbufloader-png.so''
    * potom soubor s obrázkem celý přečetl
    * pharaon soubor vůbec neotevřel snažil se otevírat nějaký soubor flatpak-info

  * když jsem na pharon spustil strace více ukecaný, tak jsem se konečně dozvěděl, co se děje :)

<code>
strace -vf -s 1024 ./thumb-sampl3 /home/djbuldog/Pictures/Snímek\ z\ 2014-11-18\ 20\:27\:27.png 
..
pid 15953] execve("/usr/bin/bwrap", ["bwrap", "--ro-bind", "/usr", "/usr", "--ro-bind", "/lib", "/lib", "--ro-bind", "/lib64", "/lib64", "--proc", "/proc", "--dev", "/dev", "--symlink", "usr/bin", "/bin", "--symlink", "usr/sbin", "/sbin", "--chdir", "/", "--setenv", "GIO_USE_VFS", "local", "--unshare-all", "--die-with-parent", "--bind", "/tmp/gnome-desktop-thumbnailer-YVNH9Y", "/tmp", "--ro-bind", "/home/djbuldog/Pictures/Sn\303\255mek z 2014-11-18 20:27:27.png", "/tmp/gnome-desktop-file-to-thumbnail.png", "--seccomp", "5", "/usr/bin/gdk-pixbuf-thumbnailer", "-s", "256", "file:///tmp/gnome-desktop-file-to-thumbnail.png", "/tmp/gnome-desktop-thumbnailer.png"], ["WINDOW_MANAGER=/usr/bin/compiz", .....
...
pid 15953] write(2, "Creating new namespace failed, likely because the kernel does not support user namespaces.  bwrap must be installed setuid on such systems.", 139 <unfinished ...>
..
</code>

  * on se snaží spusitt bwrap (BubbleWrap), což je [[https://wiki.archlinux.org/index.php/Bubblewrap| lightweight setuid sandbox application developed from Flatpak]] 
  * dělá to asi kvůli zvýšení bezpečnosti
    * např. ta zranitelnost spuštění škodlivého kódu přes wine při pokusu extrahovat ikonu z exe souboru
  * kontroloval jsem, že bwrap má nastaven setuidbit, ale v kernel ty user namespaces (''CONFIG_USER_NS'') nemám 


  * zapnutí v kernel napomohlo :D
  * debian prý by default blokuje user namespaces přes sysctl
    * je vůbec ten usernamespace v kernel potřeba? neměl by stačit ten setuidbit?
  * tohle se snaží udělat thumbnail-factory

<code>
mkdir /tmp/gnome-desktop-thumbnailer-Y8FU9Y
"/usr/bin/bwrap" "--ro-bind" "/usr" "/usr" "--ro-bind" "/lib" "/lib" "--ro-bind" "/lib64" "/lib64" "--proc" "/proc" "--dev" "/dev" "--symlink" "usr/bin" "/bin" "--symlink" "usr/sbin" "/sbin" "--chdir" "/" "--setenv" "GIO_USE_VFS" "local" "--unshare-all" "--die-with-parent" "--bind" "/tmp/gnome-desktop-thumbnailer-Y8FU9Y" "/tmp" "--ro-bind" "/home/djbuldog/Pictures/Sn\303\255mek z 2014-11-18 20:27:27.png" "/tmp/gnome-desktop-file-to-thumbnail.png" "--seccomp" "5"  "/usr/bin/gdk-pixbuf-thumbnailer" "-s" "256" "file:///tmp/gnome-desktop-file-to-thumbnail.png" "/tmp/gnome-desktop-thumbnailer.png"
</code>

  * výsledek

<code>
bwrap: Creating new namespace failed, likely because the kernel does not support user namespaces.  bwrap must be installed setuid on such systems.
</code>

  * přes strace jsem našel jen jedno podezřelé (za to může asi to zakázané user ns přes sysctl?)

<code>
stat("/sys/module/user_namespace/parameters/enable", 0x7ffee7d684b0) = -1 ENOENT (No such file or directory)
</code>

  * zjistil jsem, že problém jde replikovat nejjednodušeji takhle

<code>
bwrap --unshare-all bash
</code>

  * hele.. a co dělá ten unshare-all? teď jsem zjistil, že existuje unshare-pid, unshare-net... nemusím mít kvůli tomu víc těch  namespaces v kernelu?
    * https://github.com/projectatomic/bubblewrap/issues/139
  * zapnul jsem namespace pro PID, UTS, IPC a jede to !!! :)