[gelöst] tmux - unklarer Skript Code

[Newbiemint]

Hey,

ich habe folgende Linuxkonfiguration Desktop: Cinnamon 4.8.6 Distro: Linux Mint 20.1 Ulyssa und habe ein Problem bei einem Skript mit tmux-Befehlen.

Der Code-Ausschnitt, um den es mir geht ist:

Code: [Auswählen]

tmux has-session -t kbdemu
if [ $? != 0 ]; then
    tmux new-session -s kbdemu -n os -d
    tmux split-window -h -t kbdemu
    tmux split-window -v -t kbdemu:os.0
    tmux split-window -v -t kbdemu:os.1
    tmux split-window -v -t kbdemu:os.3
Ich kannte tmux bisher noch nicht, aber für mein Verständnis sollte dieser Code tmux Fenster öffnen, nachdem geprüft wurde, in bereits eine Session mit selben Namen besteht ,oder? Bei mir passiert da irgendwie garnix.
tmux selber hab ich installiert  und wenn ich

Code: [Auswählen]

tmux in die Konsole eingebe, switcht die in die tmux Ansicht.
Weiß jemand, wieso das nicht funktioniert?
Schon einmal vielen Dank für Eure Hilfe!

[Patchpanel]

Bei mir passiert da irgendwie garnix.

Da kann ja auch nichts im Vordergrund passieren, weil Du die tmux-Session "detached" startest, also im Hintergrund. Wenn Du die angegeben Befehle (bis auf die if-Condition) einzeln im Terminal eingibst und als letztes dann

Code: [Auswählen]

tmux attachdann verschiebt sich tmux in den Vordergrund und Du siehst,  dass alles korrekt eingerichtet wurde.

BTW, wenn Du Script-Code postest, dann solltest Du keinen fehlerhaften resp. unvollständigen Abschnitt posten, sondern vom Shebang angefangen bis zur letzten Zeile alles. Der hier gezeigte Code ist definitiv fehlerhaft, weil die if-Condition nicht geschlossen wurde. Wie soll man denn bei solchen Voraussetzungen bei der Fehlersuche helfen, damit es nicht nur rätselraterei sein wird?

[Newbiemint]

Hey,
danke für deine Antwort. Der Code ist aus einem gitHub Projekt: https://github.com/SySS-Research/bluetooth-keyboard-emulator/blob/master/start.sh

TW, wenn Du Script-Code postest, dann solltest Du keinen fehlerhaften resp. unvollständigen Abschnitt posten, sondern vom Shebang angefangen bis zur letzten Zeile alles. Der hier gezeigte Code ist definitiv fehlerhaft, weil die if-Condition nicht geschlossen wurde. Wie soll man denn bei solchen Voraussetzungen bei der Fehlersuche helfen, damit es nicht nur rätselraterei sein wird?

Mir ging es primär um das Verständnis dieses Ausschnitt, aber du hast natürlich Recht.

dann verschiebt sich tmux in den Vordergrund und Du siehst,  dass alles korrekt eingerichtet wurde.

Das hab ich jetzt auch festgestellt, nachdem ich mir ein paar Tutorials angeschaut habe.

So ganz check ich den Code aber immer noch nicht.
Gibt es irgendwo eine Aufschlüsselung, was diese ganzen Optionen bedeuten?
-d steht für detached, wie ich jetzt rausbekommen habe. -v und -h vertikal und horizontal
Aber was bedeutet -s -n
und was bedeutet der Doppelpunkt hinter der target session kbdemu:os.0

dann verschiebt sich tmux in den Vordergrund und Du siehst,  dass alles korrekt eingerichtet wurde.

In Verbindung mit dem oben verlinkten Skript:
Dort werden anschließenden noch Befehle an die einzelnen panes gesendet. Diese erfordern jedoch root Rechte, sodass diese bei der Passworteingabe stecken bleiben. Gibt es eine Möglichkeit die panes beim erstellen mit root-Rechten auszustatten, sodass das Skript einmal durchlaufen kann? Bzw. das Skript in einem Terminal mit root-Rechten zu starten?

[Patchpanel]

So ganz check ich den Code aber immer noch nicht. Gibt es irgendwo eine Aufschlüsselung, was diese ganzen Optionen bedeuten?

Ja sicher, guckstu...

Code: [Auswählen]

man tmux... was übrigens bei allen Linux-Terminalbefehlen funktioniert.

Aber was bedeutet -s -n

"new-session [-AdDEP] [-c start-directory] [-F format] [-n window-name] [-s session-name] [-t group-name] [-x width] [-y height] [shell-command]
                   (alias: new)
             Create a new session with name session-name."

Steht auch bei 'man tmux'

und was bedeutet der Doppelpunkt hinter der target session kbdemu:os.0

Symbolischer Name... um (irgendwann) einen Keycode an den zweifelsfrei richtigen Bildschirm einer Session senden zu können.

Genau deswegen:

Dort werden anschließenden noch Befehle an die einzelnen panes gesendet.

Diese erfordern jedoch root Rechte, sodass diese bei der Passworteingabe stecken bleiben. Gibt es eine Möglichkeit die panes beim erstellen mit root-Rechten auszustatten, sodass das Skript einmal durchlaufen kann? Bzw. das Skript in einem Terminal mit root-Rechten zu starten?

Komm bloß nicht auf die bekloppte Idee, die Script-Befehle dann mit diesem sudo-Schwachsinn auszustatten.... das ist ein NoGo. Wenn das Script root-Rechte benötigt, dann solltest Du es so starten, dass es selber unter UID 0 (root) läuft. Der schlechte Weg ist es, das Script unter Normal-User-Rechten zu speichern, es dann aber mit 'sudo' zu starten. Das funktioniert, aber es bedeutet faktisch die Deaktivierung jeglicher Betriebssystem-Sicherheit. Korrekt wäre es, das Script direkt durch root zu starten, nicht mit 'sudo', sondern entweder nach einem Kontextwechsel mit "su -" oder -wenns beim Systemstart passieren soll- mithilfe einer Service-Unit.

[Newbiemint]

Hey Patchpanel,
super vielen Dank für deine ausführliche Antwort!

Steht auch bei 'man tmux'

Top, danke!

Komm bloß nicht auf die bekloppte Idee, die Script-Befehle dann mit diesem sudo-Schwachsinn auszustatten.... das ist ein NoGo. Wenn das Script root-Rechte benötigt, dann solltest Du es so starten, dass es selber unter UID 0 (root) läuft. Der schlechte Weg ist es, das Script unter Normal-User-Rechten zu speichern, es dann aber mit 'sudo' zu starten. Das funktioniert, aber es bedeutet faktisch die Deaktivierung jeglicher Betriebssystem-Sicherheit. Korrekt wäre es, das Script direkt durch root zu starten, nicht mit 'sudo', sondern entweder nach einem Kontextwechsel mit "su -" oder -wenns beim Systemstart passieren soll- mithilfe einer Service-Unit.

Im Readme des GitHubProjektes wird vorgeschlagen das Sktript selber mit sudo ./skriptname.sh im Terminal zu starten-> das ist eher nicht so günstig, wenn ich dich richtig verstanden habe, oder?
Wenn ich mich im Terminal mit su anmelde und dann das Skript mit ./skriptname.sh ausführe - wo ist da der Unterschied? Die Berechtigungen sind doch dann dieselben, oder? Was genau verhindert diese Variante?

[aexe]

Wenn ich mich im Terminal mit su anmelde …

Geht das denn überhaupt mit LM-20.1?

Code: [Auswählen]

user@debbie-x1:~$ su
Passwort:
su: Fehler bei Authentifizierung LMDE4

[Patchpanel]

Wenn ich mich im Terminal mit su anmelde und dann das Skript mit ./skriptname.sh ausführe - wo ist da der Unterschied? Die Berechtigungen sind doch dann dieselben, oder? Was genau verhindert diese Variante?

Das ist korrekt. Systemtechnisch betrachtet läuft das Script in beiden Fällen unter UID 0, also kein Unterschied. Sicherheitstechnisch beinhalten die beiden Varianten aber einen großen Unterschied. Es ist z.B. nur mit expliziter Zusatzsoftware (z.B. ein  Keylogger) möglich, die unmittelbare Eingabe des root-Passwords beim Kontextwechsel mit 'su -' abzugreifen. Bei der Verwendung von 'sudo' ist das jedoch gar nicht notwendig, mit der Default-sudo-Konfiguration kann sich eine beliebige unter User-ID laufende Anwendung durch Abgreifen des sudo-Timeouts einfach selber eine  root-Berechtigung vergeben... du wirst das nie merken, hast aber danach definitiv keine Kontrolle mehr darüber, wer auch den Rechner verwendet. 

Also nicht hier insbesondere ist 'sudo' eine Problemquelle, sondern es ist das ganz allgemein. Mit anderen Worten, wenn Du ganz allgemein 'sudo' verwendest und damit die System-Sicherheit außer Kraft gesetzt hast, kannst Du selbstverständlich auch dieses Script mit sudo starten. Das funktioniert natürlich.... und lediglich hier auf sudo zu verzichten bringt tatsächlich keinen Nutzen. Es wäre also eine generelle Entscheidung für Deinen Rechner zu treffen.

Vor einigen Jahre war das vielleicht alles noch kein Thema, aber bei dem derzeit fortschreitenden Demokratie-Abbau, der aktiven Beseitigung von Grundrechten, sowie der digitalen Entmündigung aller Bürger wird das über Kurz oder Lang zu einem sehr relevanten Thema werden, siehe Link... wo mit der Verwendung von 'sudo' schlichtweg eine pauschale Eintrittserlaubnis erteilt wird:

https://netzpolitik.org/2021/bundespolizeigesetz-grosse-koalition-will-staatstrojaner-gegen-personen-einsetzen-die-noch-keine-straftat-begangen-haben/

[Newbiemint]

Ahh, okay, d.h. die Passworteingabe beim Wechsel zu su ist schwerer zu loggen als die Bestätigung von sudo mit dem selben Passwort (beides aus einem Terminal heraus der nicht unter root läuft)? Technisch versteh ich das nicht ganz, warum das so ist, aber das ist wahrsch auch nicht in drei Sätzen erklärt, oder?

Der verlinkte Artikel ist auf jedenfall interessant, war mir nicht bewusst.

Aber erstmal vielen Dank für deine Hilfe!

[aexe]

Default-sudo-Konfiguration

beinhaltet auch die Option, die zeitlich befristete Gültigkeit der Passworteingabe abzuschalten. Die könnte Sicherheitsbewußten vielleicht Ängste nehmen
Gibt man einen Befehl mit "sudo -k" ein, wird der Timestamp auf Null gesetzt und das Rootrecht gilt nur für den zusammen damit ausgeführten Befehl. Jede weitere Eingabe, die erhöhte Rechte erfordert, wird dann nur mit erneuter Passwortabfrage funktionieren. Kann jeder im Terminal ausprobieren:

Code: [Auswählen]

user@deb11-X1:~$ sudo -k apt clean
[sudo] Passwort für user:
user@deb11-X1:~$ sudo apt update
[sudo] Passwort für user:

-k, --reset-timestamp

Wenn diese Option ohne Befehl verwendet wird, werden die zwischengespeicherten Anmeldeinformationen des Benutzers ungültig. Mit anderen Worten, wenn sudo das nächste Mal ausgeführt wird, ist ein Kennwort erforderlich.
Diese Option erfordert kein Kennwort und wurde hinzugefügt, um es einem Benutzer zu ermöglichen, sudo-Berechtigungen aus einer .logout-Datei zu entziehen.

Wenn diese Option in Verbindung mit einem Befehl oder einer Option verwendet wird, die möglicherweise ein Kennwort erfordert, führt sie dazu, dass sudo die zwischengespeicherten Anmeldeinformationen des Benutzers ignoriert. 
Infolgedessen wird sudo nach einem Passwort fragen (falls ein solches in der Sicherheitsrichtlinie verlangt wird) und aktualisiert die zwischengespeicherten Anmeldeinformationen des Benutzers nicht.
"sudo -k"  wirkt auch, wenn es ohne verbundenes Kommando eingegeben wird.

sagt man sudo (Übersetzung)

edit
bei der nächsten "sudo" Eingabe (ohne -k) wird selbstverständlich der timestamp wieder gesetzt.

[Patchpanel]

Technisch versteh ich das nicht ganz, warum das so ist, aber das ist wahrsch auch nicht in drei Sätzen erklärt, oder?

Das ist relativ einfach erklärt und braucht auch keine 3 komplizierten Sätze.

'sudo' hat in der Default-Einstellung einen Berechtigungstimeout mehrere Minuten lang... und genau dieser Timeout kann dann, wenn Du ein sudo-Statement abgesendet hast, von jeder unter Deiner UID laufenden Prozess (indirekt) ebenfalls verwendet werden... das geht über den Umweg .bashrc. Probiers einfach aus.... gib 2 sudo-Befehle direkt hintereinander ein, die Password-Abfrage erfolgt bei sudo-Default-Konfiguration nur für den ersten Befehl.... und genau das begründet das Problem.

Du kannst natürlich auch sudo besser (?) konfigurieren, in dem Du den Timeout abschaltest.... allerdings halte ich das für die zweit-dümmste Lösung. Weil Du dann bei jedem einzelnen Statement die root-Password-Eingabe wiederholen musst. In dem Falle wäre es viel einfacher, sich einmal via 'su -' als root anzumelden, tun was zu tun ist und sich nach erfolgter Arbeit wieder abmelden. 'sudo' in Buntu-Manier zu verwenden bedeutet nichts anderes, als sudo zweckentfremdet zu verwenden. Das muss aber jeder für sich selber entscheiden.

[aexe]

Du kannst natürlich auch sudo besser (?) konfigurieren, in dem Du den Timeout abschaltest...

Nicht notwendig, siehe AW #8.

[Newbiemint]

Wisst ihr zufällig auch, wo/wie ich die tmux.conf File finde?
(Möchte dort den Maussupport dauerhaft anstellen.)