rm -r * nicht erlauben

[ubik]

Hallo,

ich hätte eine Frage:

Wie kann ich es dem System verweigern, sich selbst komplett zu löschen? Und wie kann ich es dem System verweigern, das komplette home-Verzeichnis zu löschen?

Ich finde, dass der Befehl rm -r * einen großen Schaden anrichten kann, wenn man ihn versehentlich im / oder /home/benutzer Verzeichnis benutzt.

Wie kann ich das Problem umgehen?

[slughorn]

Indem Du den Befehl gar nicht erst eintippst!

[Tintom]

Du könntest mit einem alias arbeiten, z.B. alias rm='rm -i'.

[tobo]

Die Frage haben sich überraschenderweise schon andere gestellt:
https://serverfault.com/questions/33708 ... es#tab-top

[Meillo]

Du könntest mit einem alias arbeiten, z.B. alias rm='rm -i'.

Wegen des Gewoehnungseffekts ist das mehr schaedlich als hilfreich. Man sollte darauf verzichten `rm -i' zum Default zu machen. Das wurde schon vielfach im Netz diskutiert.

Der Tipp mit der `-i'-Datei in tobos Link ist hilfreicher, weil der nur selektiv `-i' aktiviert.

Das Thema, dass Unix ein scharfes Messer ist, mit dem man sowohl gut arbeiten kann als auch sich schneiden, ist, seit es Unix gibt, immer und immer wieder bearbeitet worden. Noch immer ist Unix so wie es ist. Es wird also so besser sein als anders. Darum ist diese Diskussion hier etwas muessig -- sie ist schon tausende Male gefuehrt worden. Recherchen nach diesen Diskussionen werden vermutlich alle Antworten liefern, die man dazu bekommen kann.


Dieser Thread hier im Forum geht in eine aehnliche Richtung:
viewtopic.php?f=13&t=161287
Er beleuchtet einige Sichtweisen.

[hikaru]

Der Tipp mit der `-i'-Datei in tobos Link ist hilfreicher, weil der nur selektiv `-i' aktiviert.

Dass das funktioniert ist natürlich im konkreten Fall schön, aber ich finde es konzeptuell hässlich.

Ich finde, Dateinamen sollten grundsätzlich nicht zu Parametern expandierbar sein.* Dass es doch geht, scheint mir fast einen Bugreport wert. Aber angesichts dessen, wie hoch dieser Bug hängt, kriege ich Höhenangst.


*) Ich könnte jetzt anfangen, mit Injections zu argumentieren (à la "Little Bobby Tables"), aber es geht mir tatsächlich um's rein theoretische Prinzip.

[Meillo]

Der Tipp mit der `-i'-Datei in tobos Link ist hilfreicher, weil der nur selektiv `-i' aktiviert.

Dass das funktioniert ist natürlich im konkreten Fall schön, aber ich finde es konzeptuell hässlich.

Ich find's auch nicht gut. Darum habe ich ``hilfreicher'' und nicht ``hilfreich'' geschrieben. Wahrscheinlich haette ich noch deutlicher sein sollen. (Man sollte keine Posts unter Zeitdruck fertig schreiben. ) Schoen ist es nicht, aber selten schoen schon. Ein bisschen wie Duff's Device ... eine coole Sache halt. Aber in der Praxis nicht ganz das Richtige, denn wer eine `-rf'-Datei fuerchtet, verwendet eh immer ``rm -- *'', und da greift das `-i' dann nicht mehr.

Dieses safe-rm ist wohl der beste Ansatz, denn das kann scheinbar (ich hab's nie verwendet) Dateien selektiv blacklisten und zwar zuverlaessig, weil es rm(1) ersetzt.

Ich finde, Dateinamen sollten grundsätzlich nicht zu Parametern expandierbar sein.* Dass es doch geht, scheint mir fast einen Bugreport wert.

Es ist doch so, dass technisch gesehen in der Shell gar kein Unterschied zwischen dem was du Parameter nennst, also Flags und Optionen, und Dateinamensargumenten besteht. Das alles sind Parameter/Argumente fuer das auszufuehrende Programm. Nur dieses interpraetiert sie anhand der Reihenfolge und Syntax unterschiedlich. Dass ueblicherweise diejenigen, die mit meinem Minus anfangenden, als Flags gewertet werden, ist nur Konvention, nicht aber technisch gegeben. Siehe beispielsweise dd(1). Das Globbing geschieht in der Shell; die Interpraetation im Programm.

Wenn du explizit trennen willst, dann verwende `--' (bei den Programmen, die das unterstuetzen).

[hikaru]

Ich find's auch nicht gut. Darum habe ich ``hilfreicher'' und nicht ``hilfreich'' geschrieben. Wahrscheinlich haette ich noch deutlicher sein sollen. (Man sollte keine Posts unter Zeitdruck fertig schreiben. )

Ich hatte an deiner Aussage nichts auszusetzen, weder an deren Inhalt noch an der Klarheit.
Mir ging es um den Sachverhalt an sich.

Es ist doch so, dass technisch gesehen in der Shell gar kein Unterschied zwischen dem was du Parameter nennst, also Flags und Optionen, und Dateinamensargumenten besteht. Das alles sind Parameter/Argumente fuer das auszufuehrende Programm. Nur dieses interpraetiert sie anhand der Reihenfolge und Syntax unterschiedlich. Dass ueblicherweise diejenigen, die mit meinem Minus anfangenden, als Flags gewertet werden, ist nur Konvention, nicht aber technisch gegeben. Siehe beispielsweise dd(1). Das Globbing geschieht in der Shell; die Interpraetation im Programm.

Da hast du vermutlich recht, so genau habe ich darüber noch nicht nachgedacht. Ich bin fast versucht, mir den Quellcode der Coreutils oder Bash (Builtins) anzuschauen. Aber momentan siegt die Müdigkeit und ab morgen vermutlich die Faulheit.

[breakthewall]

Eigentlich ist rm nur eines von vielen Userspace-Programmen, die auf systemweite Syscalls wie unlink() oder auch remove() zurückgreifen, die primär von der glibc im Zusammenspiel mit dem Linux-Kernel bereitgestellt werden. Selbst wenn rm löschen oder sperren würdest, könntest nicht verhindern, dass irgendwelche Daten durch andere Programme gelöscht werden. Willst Daten gegen beabsichtigte oder unbeabsichtigte Löschung/Manipulation schützen, dann kannst bspw. mit "chattr +i Datei" oder direkt mit read-only Volumes arbeiten, die jedoch eine Aufteilung des Systems in mehrere Segmente erfordern. So könntest dann Volumes wie /, /boot und weiteres, einfach dauerhaft read-only mounten, womit kein Nutzer inkl. Root irgendetwas löschen oder verändern kann. Und diese Restriktionen bleiben bestehen, bis das seitens Root wieder aufgehoben wird. Alternativ können auch LSMs wie SELinux oder AppArmor genutzt werden, um mittels übergeordneter Rechte gewisse Daten zu schützen.

[Meillo]

Es ist doch so, dass technisch gesehen in der Shell gar kein Unterschied zwischen dem was du Parameter nennst, also Flags und Optionen, und Dateinamensargumenten besteht. Das alles sind Parameter/Argumente fuer das auszufuehrende Programm. Nur dieses interpraetiert sie anhand der Reihenfolge und Syntax unterschiedlich. Dass ueblicherweise diejenigen, die mit meinem Minus anfangenden, als Flags gewertet werden, ist nur Konvention, nicht aber technisch gegeben. Siehe beispielsweise dd(1). Das Globbing geschieht in der Shell; die Interpraetation im Programm.

Da hast du vermutlich recht, so genau habe ich darüber noch nicht nachgedacht. Ich bin fast versucht, mir den Quellcode der Coreutils oder Bash (Builtins) anzuschauen. Aber momentan siegt die Müdigkeit und ab morgen vermutlich die Faulheit.

Um deine Motivation zu erhoehen und den Aufwand zu reduzieren, haette ich dir gerne den direkten Link ins CVS der Heirloom-Tools gepostet, weil du bei denen sehr viel weniger Code zu lesen hast, und darum schneller und klarer siehst, was Sache ist als wenn du die GNU-Tools anschaust. Leider scheint das CVS auf Sourceforge down zu sein:
http://heirloom.cvs.sourceforge.net/heirloom/heirloom/

Als Alternative wollte ich 9base (von Suckless) vorschlagen, aber dort ist die Argumentverarbeitung schwer zu verstehen, weil die mit Macros (ARGBEGIN/ARGEND) arbeiten, ausserdem unterstuetzt deren rm(1) nur `-r' und `-f'.
https://git.suckless.org/9base/tree/rm/rm.c
Die Macros sind gut versteckt:
https://git.suckless.org/9base/tree/lib9/libc.h#n925

Also ein Blick zu Freebsd:
https://svnweb.freebsd.org/base/head/bi ... iew=markup

Dort sieht man die Argumentverarbeitung ganz gut.

Im Gegensatz zu den GNU-Utils muessen bei Freebsd alle Flags vor den Dateinamen kommen. Das ist auch was POSIX als Leitlinie aufstellt:

Guideline 9:
All options should precede operands on the command line.
Guideline 10:
The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.

Wie man sieht ist dort auch `--' als Trenner festgelegt. So arbeitet auch getopt(3):
http://pubs.opengroup.org/onlinepubs/96 ... etopt.html


GNU/Linux getopt(3) kann und macht mehr. Es erlaubt auch Abweichungen von der Guideline 9:

By default, getopt() permutes the contents of argv as it
scans, so that eventually all the nonoptions are at the end.
Two other modes are also implemented. If the first charac-
ter of optstring is + or the environment variable POSIX-
LY_CORRECT is set, then option processing stops as soon as a
nonoption argument is encountered. If the first character
of optstring is -, then each nonoption argv-element is han-
dled as if it were the argument of an option with character
code 1. (This is used by programs that were written to
expect options and other argv-elements in any order and that
care about the ordering of the two.) The special argument
"--" forces an end of option-scanning regardless of the
scanning mode.

(Dass die `-i'-Datei meistens funktioniert liegt daran, dass `-' vor alphanumerischen Zeichen sortiert. Falls man aber Dateien haette, die mit z.B. `+' anfangen oder die Sortierreihenfolge des Globbings aendert (jetzt will ich nicht auch noch in POSIX nachschauen, ob die festgelegt oder frei waehlbar ist), und man sich nicht auf GNU/Linux befindet oder POSIXLY_CORRECT gesetzt hat, dann funktioniert die `-i'-Datei nicht.)


So, jetzt habe ich eine Menge geschrieben. Ich hoffe, das bietet Einstiegspunkte in eigene Recherchen. Der Kernpunkt der Frage hat allerdings weniger mit all dem zu tun, als damit, dass bei exec(2) eine einzige Liste von Argumenten uebergeben wird, die sich nicht in Flags/Optionen und sonstige Argumente/Operanden unterscheidet. Damit ist eine Trennung allein konventionsbasiert. Genau an der Stelle sind wir ja inhaltlich gestartet.

[Meillo]

@breakthewall: Hervorragender Beitrag! Das ist die korrekte technische Loesung.

[breakthewall]

@Meillo

Das zu nutzen kann man eigentlich garnicht oft genug wiederholen, zumal ich Jahre zuvor auf die harte Tour lernen musste, wie schnell der Supergau eintreten kann. Damals wurde ziemlich fahrlässig mit einer 1:1 Kopie des Host-Systems in einer Fullscreen-VM gearbeitet. Den ganzen Tag stetig hin und her geswitcht, und vieles getestet, bis zum einen Punkt an dem sehr gefährliche Befehle ausgeführt wurden, in vollster Überzeugung gerade in der VM zu sein. Und wenige Sekunden später kam der Schock, da nicht nur das Host-System geschrottet wurde, sondern auch unverzichtbare Daten von zwei eingehängten Datenträgern, für die es kein weiteres Backup mehr gab. Auch eine Wiederherstellung brachte nur größtenteils unbrauchbare Fragmente hervor. Seither nie wieder ohne read-only Volumes, was ja nebenbei auch der Systemsicherheit zuträglich ist.