Wie man sich RPM Scripte ansieht

Heute geht es um RPMs und die Install und Uninstall Scripte die RPMs so mit sich rumschleppen.

Wie man RPM-Files genauer betrachtet

Zunächst schauen wir mal in ein RPM am Beispiel des Zoomclienten für Linux rein, was überhaupt drin ist:

# rpm -ql ./zoom_x86_64.rpm

Allerdings sieht man dabei nur die Dateien des RPM, aber nicht die Scripte oder die Info des RPM:

# less zoom_x86_64.rpm

Ja, genau, less 🙂 Wer hätte das gedacht, daß dies beides gleichzeitig anzeigt 🙂

Name : zoom
Version : 2.8.183302.0415
Release : 1
Architecture: x86_64
Install Date: (not installed)
Group : default
Size : 246299262
License : see https://www.zoom.us/
Signature : RSA/SHA1, Di 16 Apr 2019 09:02:21 CEST, Key ID b903bf1861a7c71d
Source RPM : zoom-2.8.183302.0415-1.src.rpm
Build Date : Di 16 Apr 2019 08:59:45 CEST
Build Host : localhost
Relocations : / 
Packager : Zoom Linux Team <linux-dev@zoom.us>
Vendor : Zoom Video Communications, Inc.
URL : https://www.zoom.us
Summary : Zoom, #1 Video Conferencing and Web Conferencing Service \nZoom, the cloud meeting company, unifies cloud video conferencing, simple online meetings, and group messaging into one easy-to-use platform. Our solution offers the best video, audio, and screen-sharing experience across Zoom Rooms, Windows, Mac, Linux, iOS, Android, and H.323/SIP room systems.
Description :
Zoom, #1 Video Conferencing and Web Conferencing Service \nZoom, the cloud meeting company, unifies cloud video conferencing, simple online meetings, and group messaging into one easy-to-use platform. Our solution offers the best video, audio, and screen-sharing experience across Zoom Rooms, Windows, Mac, Linux, iOS, Android, and H.323/SIP room systems.
-rw-rw-r-- 1 root root 513 Jul 26 2018 /opt/zoom/Droplet.pcm
-rw-rw-r-- 1 root root 140 Sep 13 2018 /opt/zoom/Qt/WebSockets/qmldir
-rw-rw-r-- 1 root root 2637 Sep 13 2018 /opt/zoom/Qt/labs/calendar/DayOfWeekRow.qml
-rw-rw-r-- 1 root root 7835 Sep 13 2018 /opt/zoom/Qt/labs/calendar/DayOfWeekRow.qmlc
-rw-rw-r-- 1 root root 2703 Sep 13 2018 /opt/zoom/Qt/labs/calendar/MonthGrid.qml
-rw-rw-r-- 1 root root 8747 Sep 13 2018 /opt/zoom/Qt/labs/calendar/MonthGrid.qmlc
-rw-rw-r-- 1 root root 2645 Sep 13 2018 /opt/zoom/Qt/labs/calendar/WeekNumberColumn.qml
-rw-rw-r-- 1 root root 7835 Sep 13 2018 /opt/zoom/Qt/labs/calendar/WeekNumberColumn.qmlc
-rwxrwxr-x 1 root root 117816 Sep 13 2018 /opt/zoom/Qt/labs/calendar/libqtlabscalendarplugin.so
-rw-rw-r-- 1 root root 4968 Sep 13 2018 /opt/zoom/Qt/labs/calendar/plugins.qmltypes
-rw-rw-r-- 1 root root 187 Sep 13 2018 /opt/zoom/Qt/labs/calendar/qmldir
-rwxrwxr-x 1 root root 64624 Sep 13 2018 /opt/zoom/Qt/labs/folderlistmodel/libqmlfolderlistmodelplugin.so
-rw-rw-r-- 1 root root 2341 Sep 13 2018 /opt/zoom/Qt/labs/folderlistmodel/plugins.qmltypes
-rw-rw-r-- 1 root root 124 Sep 13 2018 /opt/zoom/Qt/labs/folderlistmodel/qmldir

Geht natürlich auch direkt mit rpm :

# rpm -qi foo.rpm

und wer auch die Changelogs sehen will:

# rpm -qi –changelog foo.rpm

Jetzt ging es aber um die Installationsscripte, die ausgeführt werden, wenn man Pakete installiert oder eben deinstalliert:

# rpm -qp –scripts foo.rpm

Wenn man das beim Beispiel Zoom macht, kommt das raus:

# rpm -qp –scripts zoom_x86_64.rpm

Warnung: zoom_x86_64.rpm: Header V4 RSA/SHA1 Signature, Schlüssel-ID 61a7c71d: NOKEY
postinstall scriptlet (using /bin/sh):
#!/bin/bash
# Program:
# script to be run after package installation

echo "run post install script, action is $1..."

#ln -s -f /opt/zoom/ZoomLauncher /usr/bin/zoom

#$1 folder path
function remove_folder
{
if [ -d $1 ]; then
rm -rf $1
fi
}

echo current home is $HOME
remove_folder "$HOME/.cache/zoom"

update-mime-database /usr/share/mime || true
#update-desktop-database || true
if [ -x "/usr/bin/update-desktop-database" ]; then 
update-desktop-database || true
fi
postuninstall scriptlet (using /bin/sh):
#!/bin/bash
# Program:
# script to be run after package removal

echo "run post uninstall script, action is $1 ..."

[ "$1" == "0" ] || exit 0

echo current home is $HOME

if [ -L "/usr/bin/zoom" ]; then 
rm /usr/bin/zoom 
fi

#$1 folder path
function remove_folder
{
if [ -d $1 ]; then
rm -rf $1
fi
}

#$1 file path
function remove_file
{
if [ -f $1 ]; then
rm -f $1
fi
}

remove_folder "/opt/zoom"
remove_folder "$HOME/.zoom/logs"
remove_folder "$HOME/.cache/zoom"
#remove_file "$HOME/.config/zoomus.conf"

#logged_in_users=$(who -q | head -n 1)
#sorted_users=$(echo "$logged_in_users"|tr " " "\n"|sort|uniq|tr "\n" " ")
#for user in $sorted_users;do
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom..."
# remove_folder "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom"
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf..."
# remove_file "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf"
#done

Orange ist das Installscript, Grün ist das Uninstallscript

Denn Sie wissen nicht, was Sie tun

Ok, was fällt uns daran auf?

echo current home is $HOME
...
remove_folder "/opt/zoom"
remove_folder "$HOME/.zoom/logs"
remove_folder "$HOME/.cache/zoom"

Es soll also im Home des Users etwas gelöscht werden ? Jetzt zeige ich Euch mal was das Script ausgegeben hat :

# dnf erase zoom
Abhängigkeiten sind aufgelöst.
================================================================================================================================================================================================================================================================================
Paket Arch Version Paketquelle Größe
================================================================================================================================================================================================================================================================================
Entfernen:
zoom x86_64 2.8.183302.0415-1 @@commandline 235 M

Transaktionsübersicht
================================================================================================================================================================================================================================================================================
Entfernen 1 Paket

Freigegebener Speicherplatz: 235 M
Ist dies in Ordnung? [j/N]:j
Transaktionsüberprüfung wird ausgeführt
Transaktionsprüfung war erfolgreich.
Transaktion wird getestet
Transaktionstest war erfolgreich.
Transaktion wird ausgeführt
Vorbereitung läuft : 1/1 
Löschen : zoom-2.8.183302.0415-1.x86_64 1/1 
Ausgeführtes Scriptlet: zoom-2.8.183302.0415-1.x86_64 1/1 
run post uninstall script, action is 0 ...
current home is /root
Überprüfung läuft : zoom-2.8.183302.0415-1.x86_64 1/1

Entfernt:
zoom.x86_64 2.8.183302.0415-1

Fertig.

Na? Wer hats gesehen?  … Richtig: „current home is /root“  wie sinnvoll dort Configs u.ä. zu löschen oder gar anzulegen, wo Root doch gar nicht der User ist, des es ausgeführt hat. Um das zu beheben, war der Code hier mal gedacht:

#logged_in_users=$(who -q | head -n 1)
#sorted_users=$(echo "$logged_in_users"|tr " " "\n"|sort|uniq|tr "\n" " ")
#for user in $sorted_users;do
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom..."
# remove_folder "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom"
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf..."
# remove_file "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf"
#done

Selbst wenn das einkommentiert gewesen wäre, wäre das wenig hilfreich gewesen, weil was wenn der User gar nicht eingeloggt ist, wenn das Uninstallscript läuft? Genau, dann würden die Files auch nicht gelöscht werden 😀  Da haben sie es dann gleich gelassen 😉

Einmal mit Profis und so..

Wieso habe ich das eigentlich nach Benutzung gelöscht? Ach ja, wegen der sechs CVE Sicherheitslücken allein in den statisch gelinkten QT5 Libraries seit September 2018 😀

#CVE IDCWE ID# of ExploitsVulnerability Type(s)Publish DateUpdate DateScoreGained Access LevelAccessComplexityAuthenticationConf.Integ.Avail.
1CVE-2018-19873119Overflow2018-12-262019-01-08
7.5
NoneRemoteLowNot requiredPartialPartialPartial
An issue was discovered in Qt before 5.11.3. QBmpHandler has a buffer overflow via BMP data.
2CVE-2018-198723692019-03-212019-04-24
4.3
NoneRemoteMediumNot requiredNoneNonePartial
An issue was discovered in Qt 5.11. A malformed PPM image causes a division by zero and a crash in qppmhandler.cpp.
3CVE-2018-198714002018-12-262019-04-25
4.3
NoneRemoteMediumNot requiredNoneNonePartial
An issue was discovered in Qt before 5.11.3. There is QTgaFile Uncontrolled Resource Consumption.
4CVE-2018-198704762018-12-262019-04-25
6.8
NoneRemoteMediumNot requiredPartialPartialPartial
An issue was discovered in Qt before 5.11.3. A malformed GIF image causes a NULL pointer dereference in QGifHandler resulting in a segmentation fault.
5CVE-2018-19869202018-12-262019-04-25
4.3
NoneRemoteMediumNot requiredNoneNonePartial
An issue was discovered in Qt before 5.11.3. A malformed SVG image causes a segmentation fault in qsvghandler.cpp.
6CVE-2018-198655322018-12-052019-05-10
5.0
NoneRemoteLowNot requiredPartialNoneNone
A keystroke logging issue was discovered in Virtual Keyboard in Qt 5.7.x, 5.8.x, 5.9.x, 5.10.x, and 5.11.x before 5.11.3.

Den Rest der App zu analysieren habe ich mir dann gleich erspart 😉

Beworben wurde das RPM übrigens mit „ab Fedora 21“ .. das ist ja auch nur schon 4 Jahre her. Daher hat ich dann das Filedatum der Libs verwundert, denn die stammen von 2018. Ob das damit wirklich noch „ab Fedora 21“ läuft, hmm, wer weiß, ich probier es jedenfalls nicht aus 😉

1und1 DSL Kunden in Braunschweig aufgepaßt

Hallo 1und1 Kunden in und um Braunschweig,

prüft doch mal, ob Ihr noch das DTAG ( Deutsche Telekom ) – Netz oder schon das VersaTel-Netz benutzt, denn 1und1 hat ohne es an die große Glocke zu hängen, den genutzten Backbone auf die „Tochter“ VersaTel umgestellt.

Als Folge dessen, brauchen Pakete von z.B. meinem DSL-Zugang zu einem meiner Server plötzlich 5x so lange:

[marius@eve ~]$ mtr -r s129.meine-server.im.netz
Start: 2019-05-06T10:32:42+0200
HOST: eve.meine-server.im.netz Loss% Snt Last  Avg Best Wrst StDev
1.|-- fritz.box                 0.0% 10   4.9  4.7 0.6 6.2 1.5
2.|-- 62.155.243.56             0.0% 10  19.2 12.0 4.5 30.1 9.6
3.|-- 217.5.109.158             0.0% 10   6.4  6.6 6.4 6.7 0.1
4.|-- cr02.h.as24679.net        0.0% 10   6.7  6.6 6.3 6.8 0.1
5.|-- ar13.h.as24679.net        0.0% 10   6.6  8.7 6.5 16.8 3.9
6.|-- s129.meine-server.im.netz 0.0% 10   6.6  6.7 6.3 7.0 0.2
[marius@eve ~]$ mtr -r s129.meine-server.im.netz
Start: 2019-05-13T12:53:07+0200
HOST: eve.meine-server.im.netz Loss% Snt  Last  Avg Best Wrst StDev
1.|-- fritz.box                 0.0%  10  10.1  9.8  0.6 16.4 3.8
2.|-- hhb1000cihr001.versatel.d 0.0%  10  10.2  10.1 9.9 10.5 0.2
3.|-- 62.214.38.9               0.0%  10   9.5  14.0 9.2 18.3 3.9
4.|-- 62.214.37.130             0.0%  10  17.5  18.2 17.1 24.3 2.2
5.|-- ix1.as24679.net           0.0%  10  29.9  29.9 29.7 30.0 0.1
6.|-- ar13.h.as24679.net        0.0%  10  30.5  35.8 30.1 67.3 11.9
7.|-- s129.meine-server.im.netz 0.0%  10  30.1  30.3 29.7 31.8 0.6

Das hat jetzt nichts mit der Bandbreite Eures Anschlusses zu tun z.B. 50 MB/s, sondern wie lange ein Paket unterwegs ist. Das kann z.b. für Online-Games, meistens Ego-Shooter, sehr wichtig sein.

Eine Stellungsnahme von 1und1 steht derzeit noch aus. Zeit für Euch, raus zubekommen, ob Ihr jetzt auch langsamer als vorher ans Ziel kommt. Falls Fragen seien sollten, die Kontaktadresse steht im Hauptimpressum von BIB.

Update:

Auf eine entsprechend formulierte Email kam ein Anruf mit folgenden telefonisch übermittelten Aussagen:

„Normalerweise schicken wir eine Email oder einen Brief um auf solche Umstellungen hinzuweisen.“

„Ja, es gab eine Umstellung. Allerdings können wir uns nicht erklären, wieso es danach langsamer wurde.“
(Die Antwort darauf ist recht simpel: Das DTAG Netz ist besser 🙂 )

Ich wette, daß 1und1 nicht damit gerechnet hat, daß das jemand raus bekommt und dann auch noch die Pingzeiten parat hat 🙂

Dann wurde sich noch erkundigt, ob die Bandbreite ok ist, was sie ja ist. Wie oben schon erklärt, ging nur um die Pingzeiten. 1und1 meint übrigens, daß bis zu 100ms ok wären. Das wäre dann eine Verschlechterung um Faktor 16,5 zum DTAG Netz. Ich denke, da hätte ich freiwillig zur DTAG gewechselt 🙂 Aber das war endlich mal ein echt gutes fachliches Gespräch mit 1und1, weil es nicht der First Level Support war, der von einem Flussdiagramm auf dem Monitor abliest 🙂

Fazit: Es macht Sinn öfter mal seine Leitung zu festen Zielen im Netz zu prüfen, die Ergebnisse zu archivieren und es gelegentlich mal zu vergleichen.