ubuntuusers.de

Hallo weise Männer und Frauen!

Bei der Arbeit habe ich eine Ubuntu 18.04-VM und ich habe seltsame Probleme beim Versuch, einige ausführbare Dateien von /bin auszuführen. Es beginnt direkt, wenn ich mich über SSH anmelde, gleich nach MOTD:

/bin/sh: 0: Can’t open /bin/lesspipe

Dienstprogramme wie zgrep, lesspipe und uncompress verursachen einen /bin/sh: 0: Can’t open /bin/<executable name> Fehler, andere jedoch nicht.

Verwirrender ist, dass z.B. bzcat funktioniert, zcat jedoch nicht.

Wenn ich die Befehle als SU ausführe, funktioniert aber alles.

Ich habe Screenshots und Protokolle meiner Untersuchung beigefügt. Ich habe sh, bash und fish ausprobiert und alle schmeissen den gleichen Fehler. Ich habe dash vorsichtshalber neu installiert und auch ein apt upgrade durchgeführt. Hat nicht geholfen.

Wichtige Hintergrundgeschichte: Dieser Server verwendet Kerberos, um Benutzer von ActiveDirectory zu authentifizieren. Nachdem ich mich angemeldet hatte, stellte ich fest, dass ich keine bash-Shell bekomme, sondern sh. Unser überladener Administrator hatte vergessen, den defaultShell-Parameter des Kontos auf /bin/bash zu setzen. Nachdem dies behoben war, bekam ich das oben beschriebene Problem.

Ich bin Ihnen sehr dankbar, wenn Sie eure Ideen zur Fehlerbehebung mitteilen können!

Zeig mal bitte die Ausgabe von

ls -lsha /bin /usr/bin 

Und bitte keine Screenshots von Shell-Ausgaben, das ist Text, den man wunderbar kopieren oder in Dateien umleiten kann - einfach in einen Code-Block (drei geschweifte Klammern drum herum) einfügen oder die Text-Datei anhängen.

Auf den ersten Blick würde ich sagen, dass den Executables die Leseberechtigungen fehlen. Normalerweise sieht das z.B. so aus (bei einer Ubuntu 20.04 Installation, wo /bin/ nur noch ein Symlink auf /usr/bin ist):

$ ls -l /usr/bin/zgrep
-rwxr-xr-x 1 root root 7585 Dez 13 16:41 /usr/bin/zgrep 

In deiner Textdatei fehlen wie man sehen kann die Leseberechtigungen:

--wx--x--x 1 root root 5,8K Apr 28  2017 zgrep

Herzlich willkommen im Forum wheezardth,

bitte gewöhne dir an, hier im Forum Codeblöcke (siehe Symbolleiste im Beitragseditor, drittes Icon von Rechts) zu verwenden. Das erhöht in der Regel die Übersicht und die Helfer müssen nicht um drei Ecken herum irgendwelche Downloads ausführen und ansehen. Und vor allem: Wenn es in einem grafischen Terminal ausgegeben wird, gibt es absolut keine Ausrede, es nicht via Markieren → Kopieren → Einfügen in einen Codeblock einzusetzen.

Zu deinem konkreten Problem kann ich mangels besseren Wissens nicht so viel beitragen. Was mich etwas verwirrt ist die geringe Dichte an r-Attributen (Leserechten). Nach meinem Verständnis sollte es unter Linux/Unix so sein, dass ich eine Datei lesen können muss, wenn ich sie ausführen will. Vielleicht vergleichst du das mit einem der Systeme, wo du keine Probleme hast und sollte es Unterschiede geben, versuch mal (ggf. mit deinem Admin) herauszufinden, was da schiefgelaufen ist.

Was mir noch unklar ist: Welche Bedeutung hat SU in diesem Kontext? Ich nehme zwar SuperUser (also effektiv root) an, aber das sagt noch nichts darüber aus, mit welchem Mechanismus du diese Berechtigungsstufe erreichst.

seahawk1986 schrieb:

Auf den ersten Blick würde ich sagen, dass den Executables die Leseberechtigungen fehlen. Normalerweise sieht das z.B. so aus (bei einer Ubuntu 20.04 Installation, wo /bin/ nur noch ein Symlink auf /usr/bin ist):

$ ls -l /usr/bin/zgrep
-rwxr-xr-x 1 root root 7585 Dez 13 16:41 /usr/bin/zgrep 

In deiner Textdatei fehlen wie man sehen kann die Leseberechtigungen:

--wx--x--x 1 root root 5,8K Apr 28  2017 zgrep

Vielen Dank, seahawk1986 und Cranvil!

Es waren tatsächlich keine Leseberechtigungen auf die Dateien im /bin.

sudo chmod 755 /bin/* 

hat alles erledigt!

Es tut mir Leid dass ich alles Fehlformatiert habe, ich bin hier neu ☹ Ich habe jetzt mich mit dem Markup ein bisschen besser bekannt gemacht.

SU hat genau SuperUser bedeutet, ich habe mit sudo <Kommando> das ausgeführt!

Ich hab aus meine history die folgende Zeile herausgegrept:

949  sudo chmod -r 775 /bin/*  

Das ist ein tippfehler gewesen (/bin anstatt ./bin im Unterordner), aber es wundert mich immer noch dass es solche Auswirkungen gehabt hat, da 775 noch Ausführungsrechte hinfügt und sollte Leseberechtigungen nicht beeinflüssen... 🙄

Vlt. hat einer von meine SuperUser buddies probiert etwas zu korrigieren und hat's noch mehr versaut...