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

[worker]

Liefere doch einfach mal nur eine Regel fuer chmod(1). Es kann ja in Pseudocode sein.

Ich bin echt alles andere als nen Coder (eher im grafischen Bereich unterwegs), aber nur mal so greenhorn-mässig:
- Lese alle Optionen in ein Array ein
- Vergleiche Option 1 mit Option 2 und mit vorgegebenem Muster auf Auffälligkeiten
- Vergleiche Option 1 mit Option ... n + 1 und mit vorgegebenem Muster auf Auffälligkeiten
- Vergleiche Option 2 mit Option 1 und mit vorgegebenem Muster auf Auffälligkeiten
- Vergleiche Option 2 mit Option ... n + 1 und mit vorgegebenem Muster auf Auffälligkeiten
- ...

Okay, soweit ist's klar, aber jetzt kommt der Knackpunkt: Was genau sind diese Auffaelligkeiten?

Eben sowas wie -R und /

Natürlich ist mir klar, dass es noch andere Kobinationen von Optionen geben kann, die unangenehme Auswirkungen haben können, aber soweit sie keine solchen fatalen auswirkungen haben, muss man sie ja auch nicht in solch ein Erkennungsmuster packen.
Die meisten Fehler kann man ja recht schnell wieder ausbügeln. Es geht mir wirklich nur um die ganz groben Schnitzer, welches ein Programm - meiner Meinung nach - erkennen sollte (um einfach besser dienlich zu sein).
Und noch einmal, für alle: Mit einer Zusatzoption, dürfte man trotz dem Erkennungsmuster das ausführen, was man will bzw. was das Programm hergibt. Z.B.: chmod --override-dumbass-actions -R 000 /
Mit ner einfachen Option liesse sich das Erkennungsmuster umgehen/ausschalten.

Das mag halt nicht zur Philosophie passen, aber ich finde so extrem viel Aufwand würde das nicht bringen, dafür aber u.U. (je nach Tool) sehr viel Nutzen.
Natürlich sollte man dann nicht anfangen faul zu werden und sagen, jo wird schon gut gehen, das Tool wird Probleme auffangen - das sollte nicht sein(!). Aber wenn es mal dummer weise passieren sollte, dann hat man einfach ein (mögliches) Auffangnetz.

Ja genau, du sprachst von den Fehlern, die deiner Meinung nach abgefangen werden sollten.

Jein. Ich sprach eigentlich von groben Fehlern. Natürlich sehe ich auch iwo das "Problem" was man jetzt genau in so ein Erkennungsmuster einbauen sollte. Beim chmod sehe ich - im Moment - nur dieses eine Problem (den Slash alleine) als ein grobes Problem.
Genau wie z.B. bei rm oder mkfs.*
Nur ein blöder antippser an der Space-Taste bei 'mkfs.ext4 / mnt/testdrive.img' und die Sache ist gelaufen

Auch ich habe mir schon durch ungeeignete root-Scripte ganze Systeme zerschossen. Das gehört dazu wenn man mit Systemrechten arbeitet und Variablen verwendet, die bis auf den Ordner / Auswirkungen haben können.

Durch Fehler lernt man - sehe ich auch so. Ist halt nur die Frage/Abwägung, ob es wirklich sein muss, dass eine unkontrollierte Möglichkeit bestehen muss (siehe "Zusatzoption") das System durch einen flüchtigen aber verheerenden Fehler zu Schrott zu machen.
Bei mir hier war es ja nicht sonderlich tragisch, aber man überlege sich nur, wenn es um echte grosse, produktive Systeme geht .... garnicht auszudenken ...

So sollte man eben dann nicht programmieren.

Das ist keine Frage von Programmieren können oder nicht können. Das ist eine Frage von "Mensch sein". Niemand ist perfekt. Es reicht nur eine Nacht nicht geschlafen haben zu können und im Job kannst halt die erforderliche Konzentration nicht mehr aufbringen ...

[owl102]

sowas wie -R und /

Das ist keine Definition, auf der man aufsetzen kann. Angenommen ich schreibe ein Programm, welches weder -R noch / als gültige Parameter hat. Wie finde ich heraus, ob irgendwelche Optionskombinationen "sowas wie -R und /" sind? Was zum Beispiel ist bei dd "sowas wie -R und /"?

[uname]

Bei "dd" reicht unter Umständen ein Vertauschen von /dev/sda und /dev/sdb . Und dort kommt -R und ein einfaches / gar nicht vor. Diesen Fehler kann das System nicht abfangen, da es durchaus gewünscht sein kann statt auf /dev/sdb auf /dev/sda zu schreiben. Alternativ kann man Windows nutzen. Da wird so lange gefragt bis man entnervt alle Rückfragen ungelesen akzeptiert.

[worker]

sowas wie -R und /

Das ist keine Definition, auf der man aufsetzen kann. Angenommen ich schreibe ein Programm, welches weder -R noch / als gültige Parameter hat. Wie finde ich heraus, ob irgendwelche Optionskombinationen "sowas wie -R und /" sind? Was zum Beispiel ist bei dd "sowas wie -R und /"?

Wie man das letztendlich programmiertechnisch regeln würde weiss ich nicht. Hab ja auch geschrieben, dass wohl jedes Tool seinen eigenen Filter haben müsste, bzw. "nur" die Muster. Die eigentliche Erkennungsroutine könnte man vielleicht in nen Library packen ... wie auch immer ... es geht doch eher um den Gedanken an sich, dass Programme sowas haben 'sollten'.

[owl102]

sowas wie -R und /

Das ist keine Definition, auf der man aufsetzen kann. Angenommen ich schreibe ein Programm, welches weder -R noch / als gültige Parameter hat. Wie finde ich heraus, ob irgendwelche Optionskombinationen "sowas wie -R und /" sind? Was zum Beispiel ist bei dd "sowas wie -R und /"?

Wie man das letztendlich programmiertechnisch regeln würde weiss ich nicht.

Davon rede ich überhaupt nicht. Ich schreibe ein Programm. Wo ist der Leitfaden, der mir Entscheidungshilfe gibt, welche Optionskombinationen unter "böse" fallen? Bisher haben wir in dem Leitfaden lediglich "sowas wie -R und /" stehen, was etwas mau ist und einen sehr (und insbesondere zu) großen Interpretationsspielraum läßt.

es geht doch eher um den Gedanken an sich, dass Programme sowas haben 'sollten'.

Wenn man möchte, daß Programme "sowas" haben sollten, dann muß man "sowas" auch genauer spezifizieren. Ein einzelnes Beispiel reicht da nicht.

[Meillo]

sowas wie -R und /

Das ist keine Definition, auf der man aufsetzen kann. Angenommen ich schreibe ein Programm, welches weder -R noch / als gültige Parameter hat. Wie finde ich heraus, ob irgendwelche Optionskombinationen "sowas wie -R und /" sind? Was zum Beispiel ist bei dd "sowas wie -R und /"?

Ich hatte aber auch nur nach dem chmod-Fall gefragt! Insofern ist die Antwort schon valide.


Okay, nach einigem Ueberlegen, denke ich, dass es ueberlegenswert gewesen waere, alleine die Kombination von `-R' und `/' zu verhindern. Das waeren zwei Zeilen im Code (d.h. keine zusaetzliche Komplexitaet) und wuerde nur den schlimmsten und am wenigsten sinnvollen Fall abfangen.

Diese `--override-dumbass-actions' Option finde ich dagegen schlecht. Man braeuchte sie gar nicht, denn wenn man den Check so einfach macht, dann kann man mittels `/.' immer noch auf das Wurzelverzeichnis anwenden. Sowas ist elegant. (Dann kaeme Slashdot vielleicht auch zu noch mehr Popularitaet. )

Insgesamt sollte natuerlich alles ein stimmiges Gesamtkonzept ergeben, insofern wuerde ich gerne fragen, ob ihr andere Tools kennt, die irgendwelche Pfadnamen speziell behandeln. Mir faellt da spontan nur tar(1) ein, das fuehrende Slashes entfernt.

Eigentlich widersprechen Spezialbehandlungen der Idee von Unix, aber wir sind hier ja sowieso auf der theoretischen Ebene gelandet, also koennen wir ja mal ein bisschen Was-waere-wenn spielen.

[worker]

Wenn man möchte, daß Programme "sowas" haben sollten, dann muß man "sowas" auch genauer spezifizieren. Ein einzelnes Beispiel reicht da nicht.

Ja, ein produktiver/konstruktiver Gedankenaustausch/Diskussion über einzelne total sinnlose Optionskombinationen wäre sicherlich eine gute Idee...
Bisher ging es ja darum, ob man sowas überhaupt berücksichtigen soll ..

Wie wäre es für den Anfang, dass man grundsätzlich erstmal nicht (ohne Extra-Option) am root-Verzeichnis (bzw. ausgehend vom root-Verzeichnis) nichts manipulieren kann, vor allem dann nicht, wenn eine Operation rekursiv wäre (-R) ..?

[worker]

Diese `--override-dumbass-actions' Option finde ich dagegen schlecht. Man braeuchte sie gar nicht, denn wenn man den Check so einfach macht, dann kann man mittels `/.' immer noch auf das Wurzelverzeichnis anwenden.

Ja, das hat schon was ...
Muss allerdings dazu sagen, dass ich pers. eine solche Option in solch einer Art und Weise noch nie so angegeben habe ^^

[MSfree]

Wie wäre es für den Anfang, dass man grundsätzlich erstmal nicht (ohne Extra-Option) am root-Verzeichnis (bzw. ausgehend vom root-Verzeichnis) nichts manipulieren kann, vor allem dann nicht, wenn eine Operation rekursiv wäre (-R) ..?

-R ist bereits eine Extraoption. Warum willst du eine Extraoption mit noch einer Exrtaextraoption "absichern"? Wenn sich die Leute dann daran gewöhnt haben, die Exrtaextraoption auch immer angeben zu müssen schreit der nächste nach eine Exrtaextraextraoption, die die Exrtaextraoption absichern, damit man mit der Extraoption keinen Schaden anrichten kann.

Nicht ohne Grund darf man im /-Verzeichnis Änderungen nur als root durchführen. Wer meint, immer als root angemeldet zu sein, weil er ja sonst nicht alles darf, hat die erste Absicherungsbarriere schon ignoriert und muß mit den Kosequnzen leben, wenn er das System hinstellt.

[worker]

@MSfree:
Thread vorher gut durchgelesen?

[MSfree]

@MSfree:
Thread vorher gut durchgelesen?

Ja

[Radfahrer]

@worker
Sieh es doch einfach ein: DU hast einen Fehler gemacht. Und der hatte für dich üble Folgen. Aber weder das System, noch irgendwelche Programmierer, noch der liebe Gott hatten Schuld daran.

Nur DU selber hattest Schuld!

Lerne daraus und gut ist.

[worker]

@worker
Sieh es doch einfach ein: DU hast einen Fehler gemacht. Und der hatte für dich üble Folgen. Aber weder das System, noch irgendwelche Programmierer, noch der liebe Gott hatten Schuld daran.

Nur DU selber hattest Schuld!

Lerne daraus und gut ist.

Hab ich irgendwo was anderes geschrieben, oder warum bist du jetzt so gereizt?!
Was soll der Mist? Was wirfst du mir vor, was ich nicht bereits von selbst eingesehen hatte?!
Wird jetzt die Diskussion hiermit absichtlich vom wahren Kern der Sache (die sich aus meinem Problem entwickelt hat) abgelenkt?!
*kopfschüttel*

Also wenn man hier nicht sachlich weiter machen will, dann soll bitte nen Mod den Thread schliessen...

[Radfahrer]

Ich bin nicht gereizt. Warum sollte ich auch?

Wenn du es selber schon eingesehen hast, warum lässt du es dann nicht einfach dabei?
Wenn du draus gelernt hast, wirst du das nächste Mal vorsichtiger sein. Somit ist doch alles gut.

Ganz unabhängig von der ellenlangen Diskussion hier:
Der Kern der Sache ist doch, dass du einen Fehler gemacht hast. Und jetzt denkst du dir was zusammen, dass irgendwer das System so ändern soll, damit du in Zukunft nicht mehr selber aufpassen musst, was du tust, sondern dass das System dich an die Hand nimmt und dir nur noch die Dinge erlaubt, die nichts kaputt machen können.


Sorry, aber das ist einfach nur kindisch. Werde mal erwachsen und lerne, die Konsequenzen deiner Fehler zu akzeptieren. Und mach da nicht so eine riesen Sache draus. Du hast dir das System zerschossen. Na und? Da bist du nicht der erste.
Spiele dein Backup zurück und mache es das nächste Mal besser.
Ach ja, du hast ja kein Backup. Warum eigentlich nicht? Weil das System keins für dich gemacht hat? Dann hast du ja schon wieder was gelernt.

Damit ist das Thema für mich auch erledigt.

[worker]

@Mod, bitte schliessen.

[Meillo]

@Mod, bitte schliessen.

Ich sehe immer noch keinen Grund zu schliessen. Als Mod will ich Diskussionen ermoeglichen, nicht sie unterbinden. (Falls du hier nicht weiter mitmachen willst, dann lese einfach die neuen Posts nicht mehr.)

Damit ist das Thema für mich auch erledigt.

Den Eindruck habe ich auch. Du hast nicht gemerkt, dass es laengst nicht mehr um das geht, worueber du schreibst. Der konkrete Fall ist schon seit Post Nummer 3 auf Seite 1 erledigt. Danach hat sich die Diskussion ins Theoretische/Akademische/Philosophische entwickelt. Ich faende es gut, wenn du uns da nicht im Weg stehen wuerdest.


Hmm ... so interessant sich das Thema auch fuer mich entwickelt hat (wie man an meinen Posts sicher erkennen kann), nach all der Konfrontation ist der gewinnbringende Austausch in diesem Thread vielleicht doch nicht mehr moeglich. (Das erinnert mich an die SystemD-Flamewars ...)

Dennoch: Fuer mich ist dieser Thread einer der wertvollsten im letzten halben Jahr. Hier war naemlich etwas dabei, das ich mitnehmen werde ... in meine Ueberlegungen, in zukuenftige Diskussionen, gut moeglich auch mal als Beispiel in einen Vortrag. Das passiert nicht allzu oft. Waere schade gewesen, wenn's hier nicht dazu gekommen waere.

[worker]

@Mod, bitte schliessen.

Ich sehe immer noch keinen Grund zu schliessen.

Ich leider schon, weil wie du schreibst:

[...] nach all der Konfrontation ist der gewinnbringende Austausch in diesem Thread vielleicht doch nicht mehr moeglich.

Ich finde es halt schade, dass einige hier nicht die Fähigkeit besitzen ein wenig über den Tellerrand zu schauen, sondern meinen man würde das angreifen woran sie 'glauben' ...

Dennoch: Fuer mich ist dieser Thread einer der wertvollsten im letzten halben Jahr. Hier war naemlich etwas dabei, das ich mitnehmen werde ... in meine Ueberlegungen, in zukuenftige Diskussionen, gut moeglich auch mal als Beispiel in einen Vortrag. Das passiert nicht allzu oft. Waere schade gewesen, wenn's hier nicht dazu gekommen waere.

Es freut mich echt, dass wenigstens einer hier fähig ist, Dinge auch mal ein wenig aus einer anderen Perspektive - als aus der angewöhnten - zu betrachten und darüber zu reflektieren, was ein anderer schreibt .

[Cae]

Aus deinem vorletzten Post:

Insgesamt sollte natuerlich alles ein stimmiges Gesamtkonzept ergeben, insofern wuerde ich gerne fragen, ob ihr andere Tools kennt, die irgendwelche Pfadnamen speziell behandeln. Mir faellt da spontan nur tar(1) ein, das fuehrende Slashes entfernt.

Im weiteren Sinne waeren da "scp-Aehnliche" (z.B. auch rsync), bei denen das erste Vorkommen von : und ggf. auch @ (was aber eher als Parameter an ssh durchgereicht wird) eine spezielle Bedeutung hat.

Irgendwo im dd/tar-Umfeld gab es auch : zur Unteraddressierung von Tapes (glaub' ich):

Code: Alles auswählen

$ tar --version | head -1
tar (GNU tar) 1.27.1
$ tar cf foo:bar a b c
tar: Cannot connect to foo: resolve failed

Die manpage kennt nichts dazu, die info-Page ebenfalls nicht. strace sagt, das wird per DNS aufgeloest, eine Suche im Quellcode foerdert lib/rtapelib.c zutage [1]. Laut ChangeLog wurde das Feature (?) um 1997 herum eingebaut. Die Idee scheint tatsaechlich zu sein, dass man gnutar als Netzwerkdaemon lauschen oder zu einem solchen verbinden lassen kannn.

more +/foo geht auch ein bisschen in diese Richtung, ist aber eigentlich kein Dateiname, es steht nur als Option an einer Stelle, wo auch eine Datei angegeben werden koennte.

Gruss Cae

[1] https://sources.debian.net/src/tar/1.27 ... ib.c/#L355