Aus Gnome MPV wurde Celluloid

„Ins Hirn geschissen“ würden Bayern wohl zurecht sagen, wenn Sie von dem neuesten Streich wüßten, der die GTK Gui von MPV erwischt hat.

Aus GNOME MPV wurde Celluloid

Da über den Namenswechsel kaum berichtet wurde, und Google hat sich wirklich ins Zeug gelegt was zu finden, ist es jetzt auch leider zu spät sich dazu zu melden. Trotzdem soll nicht unerwähnt bleiben warum denn der Name geändert wurde:

Weil „GNOME MPV“ ein wenig uninformativ ist, wie GNOME Entwickler Tobias Bernard erklärt:

„Der aktuelle Name ist etwas unelegant und passt nicht wirklich zu anderen Anwendungen auf der GNOME-Plattform. Gute App-Namen sind in der Regel ein einzelnes Substantiv, das mit der Domäne der App zusammenhängt (z.B. „Fragments“ für eine Torrent-App oder „Peek“ für einen Bildschirmrekorder).

Also alleine schon die Auflistung der Beispiele ist ja wohl an den Haaren herbei gezogen! „Torrento“ wäre ein passender Name für eine Torrent-App, aber doch nicht „Fragments“. „Peek“, was soll das bitte sein? „to peek“ meint in der Übersetzung „gucken“, „spähen“, „nachsehen“, aber doch keinen Bildschirmrekorder.

Der alte Name „GNOME MPV“ macht genau das, was angeblich gefordert ist, er beschreibt was es ist: Eine Gnomeversion von MPV. Geht es eigentlich noch besser?

eine Rasenfläche mit Häusern

Um den hier gehts!

Also: Wieso nur?

Über die wahren Gründe kann ich nur spekulieren, aber die Assoziation „Celluloid/Zelluloid“ mit Film, Popkorn und „Rahmen“ ( kannste Dir nicht ausdenken sowas s.u. ) dürfte heutzutage hinken. Wo gibt es denn noch Kinos die analoge Projektoren haben? Im Museumsdorf? Wie alt muß man bitte sein um bei „Film ansehen“ als erstes an durchsichtige Plastikstreifen mit lustigen Bildern drauf und ein Mais-Butter-Komglumerat zu denken?

Ich habe dazu die „Diskussion“ dazu gefunden: https://github.com/celluloid-player/celluloid/issues/353

Wie jemand woanders meinte, könnte Celluloid als Name allein deswegen genommen worden sein, weil alles andere schon belegt war. Das fällt einem sehr schnell auf die Füße, wenn man doppelte Appnamen hat.

Wenn man sich die „Diskussion“ oben mal durchliest, merkt man gleich, daß das nur eine Handvoll Leute entschieden hat. Wenn die sich mal in 1-2 Jahren nicht wünschen werden, daß sie das mal lieber gelassen hätten. Wer jetzt nach MPV sucht, stolpert jedenfalls nicht mehr so leicht über den Player und wer RPMFusion aktiviert hat, wird eh nur leicht irritiert drein schauen und dann nur das reine MPV installieren.

Gesagt – Getan 🙂

Diese Arbeitshypothese habe ich gleich mal getested und dabei gesehen, daß das gnome-mpv Paket noch bei „dnf search mpv“ gefunden wird, weil es vermutlich als Baserpm noch im Repo vorhanden ist. Dabei fiel mir aber auch ein neuer Videoplayer auf MPV Basis auf : deepin-movie. Leider könnt Ihr Euch die Installation schenken, weil:

[marius@eve ~]$ deepin-movie
deepin-movie: symbol lookup error: deepin-movie: undefined symbol: _ZN3Dtk6Widget9DTitlebar7setIconERK7QPixmap

Da passen wohl das exe und die referenzierten Libs nicht ganz zueinander.

Kleiner Rework gefällig?

Wenn man GNOME MPV wieder als Namen haben will, kann sich entweder eine eigene DesktopDatei nach Schreibtisch kopieren oder gleich die systemweite Desktpdatei anpassen:

[marius@eve ~]$ cat /usr/share/applications/io.github.celluloid_player.Celluloid.desktop 
[Desktop Entry]
Version=1.0
Name[bg]=Gnome MPV
Name[ca]=Gnome MPV
Name[cs]=Gnome MPV
Name[da]=Gnome MPV
Name[de_DE]=Gnome MPV
Name[eo]=Celuloido
Name[es]=Gnome MPV
Name[fr]=Gnome MPV
Name[hr]=Gnome MPV
Name[hu]=Gnome MPV
Name[it]=Gnome MPV
Name[ja]=Gnome MPV
Name[nl]=Gnome MPV
Name[pl]=Gnome MPV
Name[pt_BR]=Gnome MPV
Name[pt_PT]=Gnome MPV
Name[ro]=Gnome MPV
Name[ru]=Gnome MPV
Name[sr]=Gnome MPV
Name[sr@latin]=Gnome MPV
Name[sv]=Gnome MPV
Name[tr]=Gnome MPV
Name[zh_CN]=Gnome MPV
Name[zh_TW]=Gnome MPV
Name=Gnome MPV
...

Ein paar Sekunden nachdem Speichern der Änderungen, aktualisiert sich das Menü und alle Appnamen in Nemo und Nautilus. Bis auf den „Celluloid“ Namen im Fensterrahmen, wärs damit erstmal wieder in grünen Bereich 😉

In dem Sinne: gute Nacht.

KDE-Desktop: RCE Schwachstelle durch .desktop Dateien

Wie die Hacker News heute morgen berichten, ist im KDE 4/5 Plasma Desktop eine Schwachstelle enthalten, die durch das reine Herunterladen von manipulierten Desktopdateien ( erkennbar an den Endungen .desktop und .directory)  ausgelöst werden kann.

Schwachstelle im KDE Desktop Indexer für Plasma

Die Ursache liegt im unsicheren Indexer, der neue Dateien analysiert und für die Suchfunktion des Desktops aufbereitet.

Dabei werden Umgebungsvariablen aus der analysierten Datei übernommen, was dazu führt, daß ein Angreifer seinen Schadcode ausführen kann. Auch das Auspacken von Archiven triggert den Indexer an, so daß auch dies die Schwachstelle auslöst.

Securityforscher Dominik Penner, der die Lücke direkt an die Hacker News geschickt hat, statt sie dem KDE Security Team zu senden, schreibt dazu:

„When a .desktop or .directory file is instantiated, it unsafely evaluates environment variables and shell expansions using KConfigPrivate::expandString() via the KConfigGroup::readEntry() function,“ Penner said.

„Wenn eine .desktop oder .directory Datei instanziiert wird ( A.d.R.: muß wohl gelesen heißen ), werden auf unsichere Weise Umgebungsvariablen und Shellerweiterungen ausgewertet, in dem die Funktion KConfigPrivate::expandString() via KConfigGroup::readEntry() genutzt wird“ schreibt Penner.

Diese Schwachstelle erinnert extrem stark an die kürzlich gefundenen Schwachstellen in Exim, wo auch die  Inhalte von fremdeingelieferten Strings ausgewertet werden und zu einem Root-Exploit eskalieren.

Bis auf weiteres muß man bei Downloads und dem Auspacken von aus unbekannten/unsicheren Quellen stammenden Archiven extrem vorsichtig sein. Das KDE Team hat einen Patch angekündigt, fertig ist der aber noch nicht.

Wenn ich mich recht entsinne, hatte der Gnome Index auch kürzlich erst so eine Schwachstelle.

Kleines Update: (10:24 Uhr)

Es gibt ein Youtube Video, daß das Problem zeigt. Allerdings wird man als unbedarft neugieriger erstmal unverständlich davor sitzen. Daher möchte ich dazu eine kleine Einleitung geben:

In dem Shellfenster rechts startet Penner „nc -lp 31337“  ( 31337 = „elite“ in L33T-Speak 🙂 ). nc startet also einen Dämon und wartet auf Verbindungen. Plötzlich wird nc beendet und wirft eine Fehlermeldung aus. Das liegt daran, daß das Desktopfile, daß per Firefox runtergeladen wird, sich bzw. ein dadurch gestartetes anderes Programm zu besagtem Port 31337 verbindet.

Das zusammen demonstriert das Problem. Man kann in den Desktopdateien natürlich auch „rm -rf /“ unterbringen, oder den Download von Illegalem Filmmaterial starten.

 

TAR und die Symlinks

Von Problemen mit TAR-Backups hört man zum Glück recht selten, heute schauen wir uns mal eines dieser Probleme an: Symlinks.

Wann man Symlinks nicht erhält

Schauen wir uns erstmal an um was es geht. So sieht etc/alternatives aus:

[root@s160 tmp]# ls -la /etc/alternatives/
insgesamt 68
drwxr-xr-x 2 root root 4096 2. Aug 06:22 .
drwxr-xr-x 125 root root 12288 2. Aug 06:25 ..
lrwxrwxrwx 1 root root 39 2. Aug 06:22 cifs-idmap-plugin -> /usr/lib64/cifs-utils/cifs_idmap_sss.so
lrwxrwxrwx 1 root root 25 2. Aug 06:22 ebtables -> /usr/sbin/ebtables-legacy
lrwxrwxrwx 1 root root 37 2. Aug 06:22 ifdown -> /etc/sysconfig/network-scripts/ifdown
lrwxrwxrwx 1 root root 35 2. Aug 06:22 ifup -> /etc/sysconfig/network-scripts/ifup
lrwxrwxrwx 1 root root 26 2. Aug 06:22 ip6tables -> /usr/sbin/ip6tables-legacy
lrwxrwxrwx 1 root root 34 2. Aug 06:22 ip6tables-restore -> /usr/sbin/ip6tables-legacy-restore
lrwxrwxrwx 1 root root 31 2. Aug 06:22 ip6tables-save -> /usr/sbin/ip6tables-legacy-save
lrwxrwxrwx 1 root root 25 2. Aug 06:22 iptables -> /usr/sbin/iptables-legacy
lrwxrwxrwx 1 root root 33 2. Aug 06:22 iptables-restore -> /usr/sbin/iptables-legacy-restore
lrwxrwxrwx 1 root root 30 2. Aug 06:22 iptables-save -> /usr/sbin/iptables-legacy-save
lrwxrwxrwx 1 root root 60 2. Aug 06:22 java -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/java
lrwxrwxrwx 1 root root 68 2. Aug 06:22 java.1.gz -> /usr/share/man/man1/java-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 59 2. Aug 06:22 jjs -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/jjs
lrwxrwxrwx 1 root root 67 2. Aug 06:22 jjs.1.gz -> /usr/share/man/man1/jjs-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 51 2. Aug 06:22 jre -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 51 2. Aug 06:22 jre_11 -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 50 2. Aug 06:22 jre_11_openjdk -> /usr/lib/jvm/jre-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 51 2. Aug 06:22 jre_openjdk -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 63 2. Aug 06:22 keytool -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/keytool
lrwxrwxrwx 1 root root 71 2. Aug 06:22 keytool.1.gz -> /usr/share/man/man1/keytool-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 34 2. Aug 06:22 libnssckbi.so.x86_64 -> /usr/lib64/pkcs11/p11-kit-trust.so
lrwxrwxrwx 1 root root 45 2. Aug 06:22 libwbclient.so.0.14-64 -> /usr/lib64/samba/wbclient/libwbclient.so.0.14
lrwxrwxrwx 1 root root 23 2. Aug 06:22 mta -> /usr/sbin/sendmail.exim
lrwxrwxrwx 1 root root 19 2. Aug 06:22 mta-mailq -> /usr/bin/mailq.exim
lrwxrwxrwx 1 root root 29 2. Aug 06:22 mta-mailqman -> /usr/share/man/man8/exim.8.gz
lrwxrwxrwx 1 root root 24 2. Aug 06:22 mta-newaliases -> /usr/bin/newaliases.exim
lrwxrwxrwx 1 root root 15 2. Aug 06:22 mta-pam -> /etc/pam.d/exim
lrwxrwxrwx 1 root root 19 2. Aug 06:22 mta-rmail -> /usr/bin/rmail.exim
lrwxrwxrwx 1 root root 19 2. Aug 06:22 mta-rsmtp -> /usr/bin/rsmtp.exim
lrwxrwxrwx 1 root root 18 2. Aug 06:22 mta-runq -> /usr/bin/runq.exim
lrwxrwxrwx 1 root root 22 2. Aug 06:22 mta-sendmail -> /usr/lib/sendmail.exim
lrwxrwxrwx 1 root root 63 2. Aug 06:22 pack200 -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/pack200
lrwxrwxrwx 1 root root 71 2. Aug 06:22 pack200.1.gz -> /usr/share/man/man1/pack200-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 60 2. Aug 06:22 rmid -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/rmid
lrwxrwxrwx 1 root root 68 2. Aug 06:22 rmid.1.gz -> /usr/share/man/man1/rmid-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 67 2. Aug 06:22 rmiregistry -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/rmiregistry
lrwxrwxrwx 1 root root 75 2. Aug 06:22 rmiregistry.1.gz -> /usr/share/man/man1/rmiregistry-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 31 2. Aug 06:22 spf -> /usr/bin/spfquery.perl-Mail-SPF
lrwxrwxrwx 1 root root 27 2. Aug 06:22 spf-daemon -> /usr/bin/spfd.perl-Mail-SPF
lrwxrwxrwx 1 root root 47 2. Aug 06:22 spfquery-man-page -> /usr/share/man/man1/spfquery-perl-Mail-SPF.1.gz
lrwxrwxrwx 1 root root 65 2. Aug 06:22 unpack200 -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/unpack200
lrwxrwxrwx 1 root root 73 2. Aug 06:22 unpack200.1.gz -> /usr/share/man/man1/unpack200-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 15 2. Aug 06:22 whois -> /usr/bin/jwhois
lrwxrwxrwx 1 root root 37 2. Aug 06:22 whois-man -> /usr/share/man/man1/whois.jwhois.1.gz

In dem Verzeichnis schreiben Pakete Symlinks zu Programmen rein, die es im System doppelt gibt. Z.B.: OpenJDK mit Java 8 und Java 11 . Das Paket, welches zuletzt installiert oder aktualisiert wird, nagelt dort die Symlinks über. (Anm. so bin ich überhaupt erst zum Thema gekommen 😉 ).

Wenn man jetzt die Symlinks vor der „Katastrophe“ wieder haben will, entpackt man sein Systembackup. Weil /etc weit vorne im Archiv steht und so ein Backup auch schon mal 80-100 GB haben kann, bricht man i.d.R. ab, wenn tar -xvzf archiv.tgz etc/alternatives keine Ausgaben mehr macht, weil der Verzeichnispfad dann „durch“ ist. So spart man sich viiiieeel Zeit, oder auch nicht 🙂

Weil, wenn man dann in das Verzeichnis schaut sieht man das hier:

[root@s160 tmp]# ls -ls etc/alternatives/
insgesamt 0
0 ---------- 1 root root 0  2. Aug 09:30 cifs-idmap-plugin
0 ---------- 1 root root 0  2. Aug 09:30 ebtables
0 ---------- 1 root root 0  2. Aug 09:30 ifdown
0 ---------- 1 root root 0  2. Aug 09:30 ifup
0 ---------- 1 root root 0  2. Aug 09:30 ip6tables
0 ---------- 1 root root 0  2. Aug 09:30 ip6tables-restore
0 ---------- 1 root root 0  2. Aug 09:30 ip6tables-save
0 ---------- 1 root root 0  2. Aug 09:30 iptables
0 ---------- 1 root root 0  2. Aug 09:30 iptables-restore
0 ---------- 1 root root 0  2. Aug 09:30 iptables-save
0 ---------- 1 root root 0  2. Aug 09:30 java
0 ---------- 1 root root 0  2. Aug 09:30 ld
0 ---------- 1 root root 0  2. Aug 09:30 libnssckbi.so.x86_64
0 ---------- 1 root root 0  2. Aug 09:30 libwbclient.so.0.14-64
0 ---------- 1 root root 0  2. Aug 09:30 mta
0 ---------- 1 root root 0  2. Aug 09:30 mta-mailq
0 ---------- 1 root root 0  2. Aug 09:30 mta-mailqman
0 ---------- 1 root root 0  2. Aug 09:30 mta-newaliases
0 ---------- 1 root root 0  2. Aug 09:30 mta-pam
0 ---------- 1 root root 0  2. Aug 09:30 mta-rmail
0 ---------- 1 root root 0  2. Aug 09:30 mta-rsmtp
0 ---------- 1 root root 0  2. Aug 09:30 mta-runq
0 ---------- 1 root root 0  2. Aug 09:30 mta-sendmail
0 ---------- 1 root root 0  2. Aug 09:30 spf
0 ---------- 1 root root 0  2. Aug 09:30 spf-daemon
0 ---------- 1 root root 0  2. Aug 09:30 spfquery-man-page
0 ---------- 1 root root 0  2. Aug 09:30 whois
0 ---------- 1 root root 0  2. Aug 09:30 whois-man

Das schockt, oder? Keine Symlinks mehr, nur noch leere Files mit 0 Byte Größe.

Was tun????

Vielleicht Man-Page lesen? Viel Spaß beim Suchen, keine Chance 🙂 Da findet sich nur dies:

-h, –dereference
Follow symlinks; archive and dump the files they point to.

Das macht TAR eh von alleine, … sagt man.  Probierts aus, ob Ihr -h im Extract drin habt oder nicht, spielt keine Rolle. Die Ursache liegt in einem kleinen Erwartungsproblem: Man erwartet, daß sobald eine Datei aus dem Archiv extrahiert wurde, diese im Filesystem auch mit allen Infos wie UID/GID, Filerechten vorhanden ist.

Da tickt tar aber leider etwas merkwürdig. Es macht das erst, wenn das Backup komplett durchlaufen wurde.

Lösung

Die Lösung lautet: Durchlaufen lassen!

Danach stimmt alles wieder, so wie man das erwarten würde. Machmal sind Lösung auch trivial. Das es im Einzelfall dann 100GB per Netzwerk sind, ist dann halt so, wenn man alles in ein Backupfile schreibt.