[ungelöst gelöst] Nach 'chmod' kein (SSH-)Login mehr möglich

[worker]

Hallo Community,

ich habe wohl einen verheereden Fehler gemacht und hoffe dass man das trotzdem wieder hinbiegen kann ...

Im Bash-Script (welches per 'sudo' ausgeführt wird) habe ich 'chmod' zusammen mit einer $Variable als Ziel benutzt. Leider hatte ich bei dem VariablenNamen einen Tippfehler und dummer weise, war nach dem VariablenNamen ein Slash ('/') mit angehängt.
Das ganze Konstrukt sieht so aus:

Code: Alles auswählen

chmod -R 770 $PFAD/

Ich denke, dass hier 'chmod' ab dem Root-Verzeichnis ('/') "herumgepfuscht" hat, da die Variable $PFAD ja garnicht gesetzt war, also blieb somit nur als Angabe der Zieloption das Root-Verzeichnis

Zuerst habe ich nur zähneknirrschend auf STRG+C gehämmert wie um mein Leben und da das System trotzdem weiter lief und ich damit ganz normal arbeiten konnte, dachte ich, dass es womöglich(/hoffentlich) doch nicht so schlimm war.
Doch dann musste ich feststellen, dass ich mich als normaler User nicht mehr Anmelden kann. Weder direkt am Server, noch per SSH.
Nach dem Login wird die Sitzung (und somit auch das Fenster) sofort geschlossen - Fehlermeldung also nur noch im syslog zu finden ... falls überhaupt ...
Ich kann mich nur noch als root anmelden.

Wenn ich mich versuche als normaler User anzumelden, dann kommt im syslog:
Failed at step EXEC spawning /lib/systemd/systemd: Permission denied

Hm, hab ich das System nun komplett zerschossen, oder kann man da doch noch iwas retten?
Das ist nen Proxy/Samba-Server, der im Moment so sehr fehlt, dass ... "wenn Blicke töten könnten" ...

Bin für jeden Tipp/Hilfestellung dankbar.
Gruss
worker

[hikaru]

Glückwunsch! Da hast du einen kapitalen Bock geschossen.
Sinnvoll zu retten ist da nichts mehr. Spiel das Backup ein!

[worker]

*schluck* ... *schluchtz* ...
Na Mahlzeit ...

Ja, das Backup stand als nächstes auf der Liste ... naja, nen älteres hab ich noch - es nervt trotzdem. Vieles muss ich jetzt neu/von Vorne machen :-/

Trotzdem Dank
w.

[hikaru]

Die geänderten Konfigurationen könntest du vor dem Restore sichern, um den Aufwand zu minimieren.

[Meillo]

Ja, das Backup stand als nächstes auf der Liste

Hehe, da bist du nicht der Erste. Nimm's locker!

[Radfahrer]

Wenigstens hast du gelernt, das ein aktuelles Backup manchmal ganz gut ist.

[worker]

@hikaru: Ja, das habe ich schon vor. Ist halt nicht wenig und vieles auch ortsmässig zerstreut ^^ ..

@Meillo: Ich versuchs locker zu nehmen

@Radfahrer: Das hatte ich schon davor einige Male gelernt

Finde trotzdem, dass solche Dinge das System abfangen sollte. Vor allem was "/" angeht. Da könnte man ne Sicherheitsabfrage oder ne extra Option dafür schaffen. Nicht nicht? ^^

So, jetzt "frisch" ans Werk - scheisse(!) .....

[Meillo]

Finde trotzdem, dass solche Dinge das System abfangen sollte. Vor allem was "/" angeht. Da könnte man ne Sicherheitsabfrage oder ne extra Option dafür schaffen. Nicht nicht? ^^

Nein!

Du haettest den abschliessenden Slash weglassen koennen, dann waere ein Fehlerstattdesse gekommen. Oder (noch besser) du haettest so ein Konstrukt verwendet:

Code: Alles auswählen

chmod -R 770 "${PFAD:-/nonexistent}/"

[worker]

Wieso "Nein" ?
Natürlich hätte ich es anders machen können - ich hätte sonst noch welche Sicherheitsmechanismen in das Script einbauen können, nur ist das halt nicht immer so eine kluge Sache, wie ich finde, ein Script eigentlich unnötig aufzublasen. Hinterher passiert ja doch genau das, was man im Script nicht berücksichtigt hat ^^ ...
Wäre so ein Feature im z.B. 'chmod' selbst, ist doch das Arbeiten an den Systemen wesentlich angenehmer(?). Man macht ja ohnehin schon genug Fehler und aber auch Sicherheitsroutinen.
Natürlich will ich damit jetzt nicht sagen, dass man faul und bequem werden soll - sicher nicht. Nur, der Mensch ist ein Mensch und keine Maschine ... zum Glück ... und 'noch' ^^ ..

[NAB]

ich hätte sonst noch welche Sicherheitsmechanismen in das Script einbauen können, nur ist das halt nicht immer so eine kluge Sache, wie ich finde, ein Script eigentlich unnötig aufzublasen. Hinterher passiert ja doch genau das, was man im Script nicht berücksichtigt hat ^^ ...

Für chmod gilt das selbe ... das würde auch nur unnötig aufgeblasen werden. Am besten wäre so eine Sicherheitsabfrage in deiner Tastatur aufgehoben.

[worker]

ich hätte sonst noch welche Sicherheitsmechanismen in das Script einbauen können, nur ist das halt nicht immer so eine kluge Sache, wie ich finde, ein Script eigentlich unnötig aufzublasen. Hinterher passiert ja doch genau das, was man im Script nicht berücksichtigt hat ^^ ...

Für chmod gilt das selbe ... das würde auch nur unnötig aufgeblasen werden. Am besten wäre so eine Sicherheitsabfrage in deiner Tastatur aufgehoben.

Deiner Argumentation kann ich nicht folgen, sorry. Wenn ich einmal in einem Programm solch einen Sicherheitsmechanismus einbaue, kann man ihn dann bei unzähligen Scripten auf unzähligen Maschinen weglassen. Das nenne ich einen Gewinn an Sicherheit und Minimierung an Code generell.
Natürlich sollte man nicht jeden "Furz" an Sicherheitsmechanismus in solche Programme einbauen, doch ich finde gerade wenn es um das "/" geht, sollte dies schon berücksichtigt werden.

[Cae]

In begrenztem Masse hilft auch set -u gegen ungesetzte ($c) aber nicht leere ($b) Variablen:

Code: Alles auswählen

$ a=foo
$ b=
$ # c is unset
$ echo .$a.$b.$c.
.foo...
$ set -u
$ echo .$a.$b.$c.
sh: 6: c: parameter not set
$ 

Im Zweifel ist ein test -e ("exists") oder genauer, test -d ("is a directory"), als vorhergehender Check sinnvoll.

Und wie schon ein wenig angeschnitten, unter unixoiden Betriebssystemen ist es ueblich, dem Benutzer so wenig unnoetige Hindernisse in den Weg zu legen ("er wird schon wissen, was er tut"). Dies gibt dem Benutzer viele Moeglichkeiten, aber auch die Moeglichkeit, das System hoechst effizient zu ruinieren.

Gruss Cae

[hikaru]

Am besten wäre so eine Sicherheitsabfrage in deiner Tastatur aufgehoben.

Das würde die Tastatur nur unnötig aufblasen. Viel besser wäre die Sicherheitsabfrage VOR der Tastatur aufgehoben. Aber das würde nur zum unnötigen Aufblasen ... ach lassen wir das.

Faustregel beim Arbeiten mit Linux:
Das System macht das was man ihm sagt, nicht das was man von ihm will. Die Verantwortung dafür, dass beides deckungsgleich ist, liegt bei einem selbst.

[Radfahrer]

Kurzfassung:
Das System macht, was man ihm sagt. Und genau das soll es ja auch.

@hikaru
Upss, zwei Stühle, ein Gedanke

[worker]

unter unixoiden Betriebssystemen ist es ueblich, dem Benutzer so wenig unnoetige Hindernisse in den Weg zu legen

Das ist mir schon klar ... leider hat es in meinem Fall (ja, ich weiss, durch meinen eigenen Fehler) Hindernisse geschaffen ^^ ..

Nachtrag: Ich möchte mich hier wirklich nicht "rumprügeln" mit Euch ... aber ein super Beispiel ist doch gerade das "rm -f /", nicht?
Das wurde ja auch ab irgendwann im Programm abgefangen - warum wohl ...
Aber wer auch das nicht einsehen möchte .... na gut, Ihr habt Recht und gut ist ....

[NAB]

Natürlich sollte man nicht jeden "Furz" an Sicherheitsmechanismus in solche Programme einbauen, doch ich finde gerade wenn es um das "/" geht, sollte dies schon berücksichtigt werden.

Wie? Du willst, dass ich chmod nicht mehr auf / anwenden kann? So ein Blödsinn. Reiß doch einfach deine 7 raus, dann hast du das Problem nie wieder, ohne dass andere Anwender unter deinen Einschränkungen leiden müssen.

Mach einfach
chmod -R 777 /
und dein System läuft wieder.

[hikaru]

Mach einfach
chmod -R 777 /
und dein System läuft wieder.

Das mögen einige Dienste wohl nicht. Die prüfen die Rechte z.B. ihrer config-Dateien (in denen Passwörter stehen könnten) und verweigern die Arbeit, wenn ihnen das Ergebnis nicht passt.

[worker]

Wie? Du willst, dass ich chmod nicht mehr auf / anwenden kann? So ein Blödsinn.

Nö, das hab ich nicht geschrieben. Im Gegenteil. Also, von wegen "wer lesen kann ..."

[Meillo]

.... na gut, Ihr habt Recht und gut ist ....

Those who do not understand UNIX are condemned to reinvent it, poorly.

UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.

Das meiste von dem was dir ``falsch'' vorkommt, wird dir irgendwann ``richtig'' vorkommen, wenn du dich nur lange genug mit Unix beschaeftigst.

[Radfahrer]

unter unixoiden Betriebssystemen ist es ueblich, dem Benutzer so wenig unnoetige Hindernisse in den Weg zu legen

Das ist mir schon klar ... leider hat es in meinem Fall (ja, ich weiss, durch meinen eigenen Fehler) Hindernisse geschaffen ^^

Das System hat absolut keine Hindernisse geschaffen. Es hat exakt das gemacht, was du von ihm verlangt hast. Besser geht es doch nicht.
Oder möchtest du ein System haben, das "Nö" sagt, wenn du ihm ein Kommando gibst? Ich nicht.

Lass dich nicht ärgern grins
Du weißt doch: "Wer den Schaden hat...."

[worker]

@Radfahrer:
Iwie glaube ich, dass man in dieser Diskussion nicht wirklich verstehen will, was sinnvoll ist bzw. was ich meinte.
Das das System (hie Linux) durchaus macht, was es soll, das ist doch die Stärke dieses Systems, und JA, man muss schon mit dem Hirn dabei sein, wenn man heikle Dinge macht - keine Frage.
Mir ging es explizit darum, zu zeigen, dass es keinen Sinn macht, wenn ich 'chmod -R 777 /' mache, dass das System dies auch ausführt. Das ist doch genau wie mit dem (bereits hier erwähnten) 'rm -f /' ... aber darauf ging hier ja auch keiner ein.
Eigentlich sollte es doch das Ziel der Programmierer auch sein, genau solche sinnbefreiten Befehlsmöglichkeiten abzufangen (und mit einer Zusatzoption trotzdem zu ermöglichen dies auszuführen - man weiss ja nie, ob nicht doch ausnahmsweise solch ein Fall eintreten könnte, welcher aber im normalen Alltag sinnfrei ist), denn das trägt in Wirklichkeit auch zur Sicherheit bei. Hier geht es nicht um die Bequemlichkeit an sich.
Jeder Mensch macht Fehler und trotzdem ist es sinnvoll gewisse Dinge per Software - aus Sicherheitsgründen - abzufangen. Dieses Feature haben doch etliche Programme. Ich erfinde hier ja auch nichts Neues.

[NAB]

Mir ging es explizit darum, zu zeigen, dass es keinen Sinn macht, wenn ich 'chmod -R 777 /' mache, dass das System dies auch ausführt.

Aber das hast du noch gar nicht gezeigt! Bisher hast du nur 'chmod -R 770 /' gezeigt!

rm -f / ist deswegen blockiert, weil es effizientere und bessere Methoden gibt, das gesamte System zu löschen - falls man das denn wirklich will - und nicht, weil es "sinnfrei" ist. Musst du jetzt aber auch nicht drauf eingehen ...

[owl102]

Eigentlich sollte es doch das Ziel der Programmierer auch sein, genau solche sinnbefreiten Befehlsmöglichkeiten abzufangen

Und wer entscheidet, ob eine Befehlsmöglichkeit sinnbefreit ist oder nicht? Der Entwickler nach gutdünken?

Und wieviele Scripte auf der Welt funktionieren nicht mehr (ohne Änderungen), nachdem solche "sinnbefreit-oder-nicht"-Checks in alle (Nicht-GUI-)Anwendungen eingeflossen sind?

[Meillo]

Iwie glaube ich, dass man in dieser Diskussion nicht wirklich verstehen will, was sinnvoll ist bzw. was ich meinte.

Das liegt halt daran, dass deine Argumentationsweise diejenige ist, die man ueblicherweise erlebt, wenn Unix-Neulinge denken, sie wuessten wie man Unix *richtig* machen muesste. Fast immer liegt es daran, dass sie Unix nicht verstanden haben. Das ist eine Erfahrungsaussage die natuerlich pauschalisiert, aber mit der Zeit wird es halt oede die gleichartige Diskussion immer wieder neu zu fuehren. Wenn ich den Eindruck haette, dass du Unix wirklich gut kennst, dann koennten wir gerne ernsthaft darueber diskutieren. (Ich bin sicher niemand der alles an Unix gut finden wuerde.)

Mir ging es explizit darum, zu zeigen, dass es keinen Sinn macht, wenn ich 'chmod -R 777 /' mache, dass das System dies auch ausführt.

Unix ist inzwischen ueber 45 Jahre alt und chmod(1) gibt es noch immer. Das liegt auch daran, dass es *keine* scheinbar sinnlosen Faelle einschraenkt, denn was Sinn macht und was nicht, das aendert sich in 45 Jahren durchaus mal ... oder auch mehrfach. Aber das wirst du schon auch noch verstehen, wenn du beginnst Unix zu verstehen.

Das ist doch genau wie mit dem (bereits hier erwähnten) 'rm -f /' ... aber darauf ging hier ja auch keiner ein.

Aber ``rm -f /'' ist doch abgesichert:

Code: Alles auswählen

$ rm -f /
rm: cannot remove `/': Is a directory

Und selbst mit `-r' ist es noch abgesichert:

Code: Alles auswählen

$ rm -rf /
rm: cannot remove `/': Permission denied

Wo ist also das Problem?


Lerne erstmal Unix zu verstehen, dann reden wir wieder ueber diese Themen.

[pferdefreund]

und wer hindert dich daran, das chmod -Programm zu kopieren (Quellotext) und ein eigenes mit Sicherheitsabfrage) draus zu machen - eventuell auch einfach ein Wrapper-Script, das den Parameter / abfragt und dann abkackt ? und dann für solche Aktionen nur den eigenen Script oder Programm verwenden. Linux und dessen Software ist frei - und ich halte es so, was mir nicht passt, mache ich mir halt passend.