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

[Meillo]

@NAB: Das war jetzt aber gar nicht konstruktiv. Gerade wo worker versucht, die Kurve noch zu kriegen ...


Ich schlage vor, dass nur noch diejenigen weiter mitdiskutieren, die ein konstruktives Interesse an der Frage haben, warum man bei chmod(1) die Kombination aus `-R' und `/' verhindern oder nicht verhindern sollte.

Und bitte: In sachlichem und ruhigem Ton.

[NAB]

War's nicht? Genau danach hatte er doch gefragt. Aber gut, ich muss hier auch niemanden überzeugen

[worker]

Gerade wo worker versucht, die Kurve noch zu kriegen ...

Genau ... dann lösch doch diesen Thread einfach und keiner muss sich meine "Müllgedanken" ansehen ...
Danke und tschüss ..

[Meillo]

Geloescht wird (aus diesem Grund) sicher nicht. Viel eher wird das Thema mal ordentlich angepackt, auf dass ein Erfolg fuer alle raus komme. Hier mein Anfang:

chmod(1) ist in der gleichen Weise abgesichert oder nicht abgesichert wie chown(1) und rm(1): Das Rechtekonzept von Unix verhindert, dass schlimme Dinge passieren, weil das System auf diesem Weg vor normalen Usern geschuetzt ist.

Weil auch fuer normale User ein rekursives rm(1) sehr destruktiv sein kann, separiert rm(1) diesen Fall ueber einen separaten Switch (`-r'). Aehnlich separiert aber auch chmod(1) den rekursiven Fall (`-R') ... wobei, da ginge es nicht anders.

``rm -r /'' ist in etwa gleich schlimm wie ``chmod -R ... /'' ... bzw. gleich sicher, denn entweder hat man die Rechte dazu oder nicht. (Analoges gilt fuer die jeweils nicht-rekursiven Varianten: die sind beide aehnlich harmlos fuer Verzeichnisse.)

Wenn man `/' besonders behandeln wollen wuerde, dann muesste man das konsequenterweise in allen diesen Tools machen (und auch bei sowas wie ``find / -delete''). Das waere ganz schoen viel Aufwand ... aber mit welchem Erfolg? Sein System kann man weiterhin zerstoeren, denn ``chmod -R ... /etc'' oder /dev oder /usr/bin ist alles auch effektiv (und in der gleichen Weise wie das fuer rm(1) gilt ... und find(1)!). Zudem: Was ist mit ``/etc/../''? Man muesste also immer erst den Pfad aufloesen ... und zwar in jedem Tool! Denn der Systemcall muss die Aktion natuerlich grundsaetzlich erlauben.


Das Problem ist doch ein anderes: Die Inflation von root! Frueher ... in the good old days ... da war Unix noch ein Mehrbenutzersystem, also das System wurde von mehreren Usern genutzt. Damals waren die allermeisten selbstverstaendlich *nicht* root. Nur ganz wenige waren root und die arbeiteten auch nur selten als Superuser. Damals wurde noch soetwas genutzt was man Gruppen nennt. Aber heute liest ja jeder Logfiles als root statt sich zum Mitglied der Gruppe adm zu machen -- die Inflation von root eben. Vielleicht sind daran auch die Paketmanager schuld, denn weil die jeder auf seinem Einzelplatzrechner nutzen koennen will, ist jeder root und das dann auch fuer andere Dinge viel zu oft. Vielleicht waere es besser gewesen, die Distributionen haetten Wege gesucht, die Paketmanagernutzung fuer die Mitglieder einer Gruppe zu erlauben, dann koennte man grossteils root-frei auskommen und viele Gefahren waere gebannt.

25 Jahre lang war das alles bei Unix kein Problem, danach hat sich die typische Nutzung der Unix-Systeme veraendert. (Da spielt sicher auch eine Gewoehnung durch Windows-Erfahrungen mit rein ... die sie unter anderem auch in vermehrten Holzhammermethoden aeussern: ``Ich weiss zwar nicht wieso es als User nicht geht, aber als root geht's immer'' oder ``Mit chmod -R 777'' geht's immer -- sowas braucht man bei Unix fast nie.)

Die Moeglichkeit jederzeit problemlos Software installieren zu koennen hat aber auch ihren Preis. Aus grosser Macht folgt grosse Verantwortung ... und wenn wir jetzt oefter root sind, dann muessen wir oefter achtsam sein. Leider ist der Effekt gegenteilig: Je mehr wir root sind, desto achtloser werden wir. *Hier* liegt das Problem, nicht in den Sicherheitsmassnahmen in Tools. Fuer Sicherheitsmassnahmen gibt es bereits ein Mittel, und das heisst Berechtigungen. Wuerde man dieses wieder angemessen einsetzen, dann muesste man nicht unzaehlige Tools verkomplizieren und damit die wahren Werte von Unix -- naemlich seine Einfachheit und seine Orthogonalitaet -- opfern.


Ich hoffe, damit habe ich einige logische Erklaerungen geliefert.

[worker]

Ah ja, jetzt kommen wir der Sache näher.
Also ist das eher eine philosophische Sache - ausgehend von dem, dass man früher eher die Gruppen-Zugriffe genutzt hat, und heute sudoet sich mal rasch lieber jeder, als dass man sich zur entspr. Gruppe addet.

Aus dieser Sicht kann ich es nachvollziehen ... trotzdem frage ich mich dann, warum - wenn die Gruppen-Zugriffe nicht (mehr so oft) genutzt werden und die "root-Inflation" statt findet - die Tools nicht ebenfalls mit der Zeit mitgehen.

Ich habs ja schon mehrfach geschrieben hier, dass man selbst für die eigenen Fehler(/Dummheit) verantwortlich ist. Doch trotzdem kann ich das nicht unter einen Hut bringen, warum eine Philosophie dem Nutzen im Wege stehen soll. Ich kann mir wirklich nicht vorstellen, dass die Tools dermassen verkompliziert werden würden, wenn man die eine oder andere Sicherheitssperre (mit expliziter Umgehungsmöglichkeit) einbauen würde. Es ist doch ein Nutzen da, und Fehler wird man ohnehin machen, auch wenn man noch so sehr aufpasst.

Ein OS einfach und transparent zu halten ist natürlich wichtig, keine Frage. Doch nur wegen einer Philosophie, welche eh im Wandel steckt, grobe Schnitzer des Admins nicht aufzufangen halte ich für - sorry - nicht zeitgemäss.

Will hier nicht die Unix-Philosophie schlecht machen - ist halt einfach meine Meinung dazu.

Btw. solche Auffangroutinen müssen garnicht so komplex sein. Man kann doch einfach kurz die angegeben Optionen miteinander abgleichen und muss auch nicht zuerst irgendwelche Systemcalls aufrufen.

Aber wenn das halt "nur" eine Frage der Philosophie ist, dann kommen wir hier wohl nicht wirklich auf einen Nenner.

[uname]

Um das Thema zu vertiefen wäre interessant zu erfahren was das eigentliche Ziel deiner chmod-Aktion war. Sicher ist nur, dass bei Mehrbenutzer-UNIX-Systemen früher niemand auf die sinnfreie Idee gekommen wäre einem nichtpriviligierten Benutzer über /etc/sudoers einen vollständigen root-Zugriff zu geben. Denn dann ist klar, dass rm oder wie in diesem Fall chmod zu einem Problem wird. Durch diese Ubuntu-sudo-Konfiguration ist der Benutzer mit dem Voranstellen von sudo der Benutzer root.
Teste es aus:

Code: Alles auswählen

sudo whoami

sudo war mal dafür gedacht, dass man einzelne Befehle nutzen darf. Hier gehört z.B. nicht mal der Editor Vim dazu, da man aus diesem Editor per Shell ausbrechen kann. Man hat damit z.B. DAU-Benutzern erlaubt das System neu zu starten falls mal Wochende ist und der Admin nicht erreichbar ist. Auch praktisch um evtl. mal einen Webserver durchzustarten oder eine Script von root zu starten, welches z.B. Logverzeichnisse aufräumt usw.

Zurück zu deinem chmod. Entweder hätten deine Benutzerrechte so sein müssen, dass der betroffene Benutzer es ohne root selbst setzen kann oder dein Gruppenrechtekonzept war einfach nur falsch. Das legt man nämlich (als root) einmalig korrekt an und dann hat es zu funktionieren. Alle von root genutzten Scripte sollte gut durchdacht sein. Und dein sudo-Script zählte leider aufgrund der falschen sudoers-Konfiguration auch zu den root-Scripten. Und das war dein Problem.

[worker]

@uname:
Ich habe mir ein Script erstellt, welches mir Datei-/Verzeichnisrechte so setzt, wie ich sie brauche - hier in Verbindung damit, dass ich im Moment einen Samba-Dienst aufsetze.
Es geht hier jedoch nicht um Samba direkt, sondern z.B. um verschiedene Freigaben. Und da ich sowas nicht mehrmals machen will - falls mal was blödes passieren (z.B. beim Experimentieren) sollte und ich die Datei-/Verzeichnisrechte erneut setzen müsste, habe ich es halt gleich in nen Script gepackt, um es bei Bedarf einfach auszuführen.

Es geht ja eigentlich nur um einen dummen Fehler von mir, aber wem ist denn sowas nicht auch schon mal passiert?!
Ein "kleiner" dummer Fehler und das ganze OS ist unbrauchbar. Und ja, es ist unbrauchbar, auch wenn man hier was anderes erzählt, denn auch wenn man nur noch als root arbeiten kann, gibt es Dienste, die können bzw. dürfen nicht als root laufen. Abgesehen davon, wenn man mehrere User eingerichtet hat, etc.

Edit: Es ist eine Serverkiste, kein Laptop, etc. - nur zur Info. Hab ich ja nicht erwähnt..

[uname]

Drei Tipps für die Zukunft:

a.) wenn schon root was ausführen soll oder muss dann das Script für root schreiben (Ordner wäre /usr/local/sbin )
b.) den Pfad so weit wie möglich fest vorgeben, evtl. mehrere Scripte nutzen (/usr/local/sbin/samba-chmod , /usr/local/sbin/apache-chmod, ...)
c.) sudo nur sinnvoll einsetzen, der Benutzer könnte z.B. für "sudo /usr/local/sbin/samba-chmod" berechtigt werden (nicht für sudo gesamt)

Wenn du aber sowieso öfter als root arbeitest kannst du das Script auch als root direkt ausführen.
Aber die Idee überhaupt ein Script zu verwenden war schon nicht schlecht. Denn Scripte führen meist zu weniger Fehler als die direkte Eingabe von Befehlsketten.

[worker]

Das ist schon klar ^^

Wenn du aber im Script die Pfade per Variable setzt und hinterher dich bei der Variable vertippst (also ist da kein Pfad, sondern nur "leerer String") und auch noch so dumm bist (nicht du, ich! ) und hinterher nen Slash machst .......

Frag mich bitte nicht warum der Slash dahinter ....... k.a., war wohl iwie abgelenkt oder sonst was ...

[uname]

Keine Variable im Script. Im Script würde auch stehen:
/usr/local/sbin/samba-chmod

Code: Alles auswählen

...
chmod -R /pfad/nach/samba/
...

Der / am Ende war dumm. Aber auch ohne Slash hätte es "kleinere" Probleme geben können wenn auch vielleicht nicht in diesem Fall.
Ist natürlich klar, dass man das Script trotzdem auf einem Testsystem ausgiebig testet

[NAB]

Es geht ja eigentlich nur um einen dummen Fehler von mir, aber wem ist denn sowas nicht auch schon mal passiert?!

Ich hab auch schon Fehler gemacht, wo ich mich nachher ins Hinterteil hätte beißen können. Damit bist du nicht alleine.

[worker]

Es geht ja eigentlich nur um einen dummen Fehler von mir, aber wem ist denn sowas nicht auch schon mal passiert?!

Ich hab auch schon Fehler gemacht, wo ich mich nachher ins Hinterteil hätte beißen können. Damit bist du nicht alleine.

Falls der Fehler so banal wie bei mir war, hast dich dann nicht geärgert, dass das System es nicht - auf welche Art und Weise auch immer - abgefangen hat?

[Meillo]

Also ist das eher eine philosophische Sache

Hey! Jetzt hast du's raus: Unix ist eine philosophische Sache! ... zumindest fuer manche.

warum [...] die Tools nicht ebenfalls mit der Zeit mitgehen.

Aus Kompatibilitaetsgruenden.

Ich kann mir wirklich nicht vorstellen, dass die Tools dermassen verkompliziert werden würden, wenn man die eine oder andere Sicherheitssperre (mit expliziter Umgehungsmöglichkeit) einbauen würde.

Btw. solche Auffangroutinen müssen garnicht so komplex sein. Man kann doch einfach kurz die angegeben Optionen miteinander abgleichen und muss auch nicht zuerst irgendwelche Systemcalls aufrufen.

Probier's aus! Ich hab dir hier ja ein paar schoene Faelle geliefert:

Sein System kann man weiterhin zerstoeren, denn ``chmod -R ... /etc'' oder /dev oder /usr/bin ist alles auch effektiv (und in der gleichen Weise wie das fuer rm(1) gilt ... und find(1)!). Zudem: Was ist mit ``/etc/../''? Man muesste also immer erst den Pfad aufloesen ... und zwar in jedem Tool!

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

Doch nur wegen einer Philosophie, welche eh im Wandel steckt, grobe Schnitzer des Admins nicht aufzufangen halte ich für - sorry - nicht zeitgemäss.

Manche sehen in der Unix Philosophie ein zeitloses Meisterwerk, dessen wahren Wert grossteils unverstanden ist ... denn sonst wuerde man nicht ``*nur* wegen einer Philosophie'' sagen ... aber mit mir hast du da halt einfach auch den Falschen gefunden. https://ulm.ccc.de/ChaosSeminar/2010/03_UnixPhil

[worker]

Btw. solche Auffangroutinen müssen garnicht so komplex sein. Man kann doch einfach kurz die angegeben Optionen miteinander abgleichen und muss auch nicht zuerst irgendwelche Systemcalls aufrufen.

Probier's aus! Ich hab dir hier ja ein paar schoene Faelle geliefert:

Sein System kann man weiterhin zerstoeren, denn ``chmod -R ... /etc'' oder /dev oder /usr/bin ist alles auch effektiv (und in der gleichen Weise wie das fuer rm(1) gilt ... und find(1)!). Zudem: Was ist mit ``/etc/../''? Man muesste also immer erst den Pfad aufloesen ... und zwar in jedem Tool!

Ja sicher, da hast du ja nicht unrecht. Natürlich müsste man konsequenter weise auch die anderen Tools anschauen und bei "Bedarf" ändern/ergänzen.

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
- ...

Vielleicht das ganze sogar in einer Library "verewigt", sodass es andere Programmierer auch nutzen könnten? Klar, der "Muster" Teil müsste wohl separat angegeben werden.

Doch nur wegen einer Philosophie, welche eh im Wandel steckt, grobe Schnitzer des Admins nicht aufzufangen halte ich für - sorry - nicht zeitgemäss.

Manche sehen in der Unix Philosophie ein zeitloses Meisterwerk, dessen wahren Wert grossteils unverstanden ist ... denn sonst wuerde man nicht ``*nur* wegen einer Philosophie'' sagen ... aber mit mir hast du da halt einfach auch den Falschen gefunden. https://ulm.ccc.de/ChaosSeminar/2010/03_UnixPhil

Ach du dicke Banane - jetzt verstehe ich ...
Aber eigentlich bin ich nen Fan vom CCC ^^.

Mir gehts doch nicht darum alles umzukrempeln, lediglich um eine minimale Erweiterung, welche das Leben ein wenig (bzw. u.U. gewaltig) erleichtert...

[Radfahrer]

Falls der Fehler so banal wie bei mir war, hast dich dann nicht geärgert, dass das System es nicht - auf welche Art und Weise auch immer - abgefangen hat?

Also ich nicht. Ich habe mich dann immer nur über mich selber geärgert. Schließlich habe ich ja den Fehler gemacht. Das System hat nur korrekt gearbeitet.

[NAB]

Falls der Fehler so banal wie bei mir war, hast dich dann nicht geärgert, dass das System es nicht - auf welche Art und Weise auch immer - abgefangen hat?

Nein. Weil ich weiß, dass es sinnlos ist vom System zu erhoffen, dass es nur genau meine Fehler abfängt. Das führt dann dazu, dass es sämtliche Fehler abfangen will, mit endlosen Sicherheitsabfragen nervt und selber besser zu wissen meint, was ich will und was nicht. Da mache ich lieber hin und wieder mal einen Fehler.

[worker]

Falls der Fehler so banal wie bei mir war, hast dich dann nicht geärgert, dass das System es nicht - auf welche Art und Weise auch immer - abgefangen hat?

Nein. Weil ich weiß, dass es sinnlos ist vom System zu erhoffen, dass es nur genau meine Fehler abfängt. Das führt dann dazu, dass es sämtliche Fehler abfangen will, mit endlosen Sicherheitsabfragen nervt und selber besser zu wissen meint, was ich will und was nicht. Da mache ich lieber hin und wieder mal einen Fehler.

Und genau darum geht es hier nicht.
Ich sprach von einem oder anderem Fehler und gemeint habe ich höchstens eine handvoll Fehler (die gröbsten), die abgefangen werden sollten (mit möglicher Option, um diese Aktion trotzdem auszuführen). Du meine güüüüte, hier muss man echt alles zehn mal schreiben ....
Jetzt darfs du dir wieder was ausdenken ..

[Meillo]

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?

[Radfahrer]

Ich sprach von einem oder anderem Fehler und gemeint habe ich höchstens eine handvoll Fehler (die gröbsten), die abgefangen werden sollten (mit möglicher Option, um diese Aktion trotzdem auszuführen). Du meine güüüüte, hier muss man echt alles zehn mal schreiben ....

Ja genau, du sprachst von den Fehlern, die deiner Meinung nach abgefangen werden sollten.
Die nächsten 10 Nutzer haben dann auch jeder eine Handvoll anderer Fehler, bei denen sie es ebenfalls möchten.
Was bringt dich zu der Auffassung, dass ausgerechnet du dir die "richtigen" Fehler ausgesucht hast, die dann auch für alle anderen "richtig" sind?

Ich möchte, dass das System genau das tut, was man ihm sagt. Ganz einfach.
Da braucht sich dann auch niemand Gedanken darüber zu machen, was es alles nicht tun soll, obwohl man es ihm sagt.

[uname]

Oft ist es so, dass Programme automatisch laufen müssen (z.B. Cron). Da stören natürlich entsprechende Sicherheitsabfragen. Bei "chmod -R 777 /" wäre es vielleicht noch gerade eine Überlegung wert, da das wirklich keiner ausführen will. Von diesen Befehlen gibt es aber viele. 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. So sollte man eben dann nicht programmieren. Wobei ich mir gerade überlege ob nicht generell versehentlich ein Leerzeichen am Ende deiner Variablen das selbe Problem produziert hätte.

[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.