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 😀