Monthly Archives: Februar 2021

Pinephone: Taschenlampen App – die Zweite

Posted on by

Hallo Linuxphone-Fans,

ich habe da mal die Taschenlampen App etwas vereinfacht und von Eurem Phosh aufrufbar gemacht.

Pinephone: Taschenlampen App – die Zweite

Auf Github habe ich Euch die Sourcen dafür heute bereitgestellt. Ok, ok.. es ging nicht eher, ich hab es erst heute geschrieben 😉

https://github.com/Cyborgscode/pinephone/tree/main/flashlight

Der Unterschied von dieser Version zu der Bash Version mit Sudo ist, es kommt ohne Sudo aus … und ist nicht mehr Bash, sondern C . Alles was Ihr zum Kompilieren braucht, ist das gcc Packet und das eine oder andere Develpaket. In einem Develpaket sind Strukturen, Definition und Macros gespeichert, die für die Benutzung einer Library benötigt werden. Man kann da auch andere Sachen reinschreiben, aber das führt jetzt zu weit.

Wie bauen wir die neue Taschenlampe jetzt?

Wenn wir uns das Makefile ansehen, welches hier wirklich ein Makefile ist und nicht ein File für den „make“ Befehl, ist die Sache ganz einfach:

gcc flashlight.c -o flashlight

Damit bauen wir das Binary, also die ausführbare Datei. Wenn Ihr das direkt auf Eurem Pinephone macht, wird da automatisch ein für die laufende Architektur gedachtes File erzeugt. Hier ist das „aarch64“. Wenn Ihr das spaßeshalber auf Eurem großen PC macht, und dann die Datei auf das Pine kopiert, werdet Ihr feststellen, daß es nicht funktioniert. Auf Eurem großen PC wurde es für x86_64 gebaut.

Ist das Binary fertig, setzen wir die nötigen Rechte: Hier „Jeder darf es ausführen und bei Ausführung darf es das als Root tun“. Wir erinnern uns: Rootrechte sind nötig, um die LED Helligkeit setzen zu dürfen.

chmod 755 flashlight
chmod u+s flashlight

Nun kopieren wir das Binary „flashlight“ an seinen Ausführungsort: /usr/local/bin

rm -f /usr/local/bin/flashlight
mv flashlight /usr/local/bin/

Jetzt noch die Desktopdatei ins passende Applicationsverzeichnis verschieben:

rm -f /usr/share/applications/flashlight.desktop
cp flashlight.desktop /usr/share/applications/

Wieso ist hier „cp“ im Spiel und nicht „mv“ wie beim Binary?

Vielleicht wollt Ihr ja mal ein Update machen und dann wär es doch Schade, wenn das Desktopfile weg wäre. Das Binary baut Ihr ja jedes mal neu, ob das für einen zweiten Durchlauf noch vorhanden ist, spielt keine Rolle. Das Desktopfile wäre dann weg 😉

Wieso ist das dem Sudo-Bash Konstrukt überlegen?

Für das korrekte Sudofile muß man wissen, wie der Username des ausführenden Benutzers lautet. Seine UID würde vielleicht auch noch gehen. Außerdem mußten wir erstmal die sudoers-Datei ändern, damit die Anweisung ausgeführt wurde. Das fällt alles komplett weg.

Damit das Programm so auf jeder Distribution einsetzbar, völlig egal von den Umständen.

Gibt es Sicherheitsbedenken?

Die gibt es immer, es ist ein SUID Programm. Nun ist in dem Programm nichts drin, was gefährlich ist, solange die echten Betriebssystem Libs benutzt werden. Schafft es ein Angreifer, dem Befehl eine eigene Kopie einer benutzten System-Lib unterzujubeln, und dafür gibt es Möglichkeiten, könnte er die Funktionsaufrüfe nutzen und einfach irgendwas anderes machen.

Ich denke aber nicht, daß das mit diesem Build möglich ist. Falls Ihr Verbesserungen habt, schickt einen Pull-Request in Github-Repo oder lasst einen Kommentar da. C ist nicht gerade mein Steckenpferd und die GCC Options schon gar nicht 😉

Wann kommt das endlich in den Fedora Build rein?

Überraschung !… Torbuntu baut schon dran 😀

Flatpaks als Platzfresser

Posted on by

Falls sich jemand gefragt hat, warum ich so ungern Flatpaks einsetze:

org.gnome.Fractal permissions:
    ipc      network              fallback-x11      pulseaudio      wayland      x11
    dri      dbus access [1]

    [1] org.freedesktop.Notifications, org.freedesktop.secrets


        ID                                                Zweig          Op        Remote         Download
 1. [✓] org.freedesktop.Platform.GL.default               20.08          i         flathub         95,3 MB / 95,9 MB
 2. [✓] org.freedesktop.Platform.GL.nvidia-460-39         1.4            i         flathub        133,2 MB / 133,3 MB
 3. [✓] org.freedesktop.Platform.ffmpeg-full              20.08          i         flathub          3,9 MB / 4,1 MB
 4. [✓] org.freedesktop.Platform.openh264                 2.0            i         flathub          1,5 MB / 1,5 MB
 5. [✓] org.gnome.Fractal.Locale                          stable         i         flathub         13,4 kB / 233,8 kB
 6. [✓] org.gnome.Platform.Locale                         3.38           i         flathub         23,8 MB / 326,1 MB
 7. [✓] org.gnome.Platform                                3.38           i         flathub        292,9 MB / 344,0 MB
 8. [✓] org.gnome.Fractal                                 stable         i         flathub          3,5 MB / 3,6 MB

Installation complete.

Das sind 3,5 MB für die Anwendung, und 570 MB für die Abhängigkeiten. Also wenn man jetzt nicht GBweise Flatpaks einsetzt ist das Verhältnis so richtig fürn Arsch. Aufm Pine waren das ungelogen sogar 1GB an Abhängigkeiten.

Und das ist nur ein Grund wieso 😉

IT Niedersachsen verwechselt Mailserver ;)

Posted on by

Aus der Reihe: „Was kann bei SMTP schon schief gehen“ heute die: IT Niedersachsen.

IT Niedersachsen verwechselt Mailserver 😉

Wenn man viel Infrastruktur hat, kann einem das schon mal passieren. Vor einigen Jahren hatte ich mal einen Beitrag über die Stadt Wolfenbüttel im IT Sec Vortrag, weil deren Mailserver komische Zertifikate für SMTP benutzt hatte, die keiner kennen konnte, weil selbst-signiert und für interne Testserver gedacht. Damals hatte deren IT das Problem, es überhaupt zu finden, weil die Microsoftlösung Ihnen einen vom Pferd erzählt hatte 🙂

Vielleicht ist das jetzt so etwas ähnliches:

Wenn man eine Email an eine Adresse schicken will, die von diesem Server bedient wird:

80.228.54.249 „inetmail23.niedersachsen.de“

Dann bekommt man im Exim das hier:

SSL verify error: certificate name mismatch: DN=“/C=DE/ST=Niedersachsen/L=Hannover/O=Land Niedersachsen/OU=IT.Niedersachsen, FG 24a/CN=inetmail14.niedersachsen.de“

Weil das ausgelieferte Zertifikat nicht mit dem Hostnamen übereinstimmt. Vermutlich wurde einfach nur das falsche Zertifikat verteilt. Witzig ist nur, daß es auf beiden Servern passiert ist, denn ein „host inetmail23.niedersachsen.de“ zeigt zwei verschiedene IPs an. Da darf man von einem Deployserverproblem ausgehen, also hat es keiner mit Handarbeit verteilt 🙂