rm -r * nicht erlauben
rm -r * nicht erlauben
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?
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
- Beiträge: 179
- Registriert: 26.01.2014 22:43:35
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Grimma; 51°14'N, 12°44'O
Re: rm -r * nicht erlauben
Indem Du den Befehl gar nicht erst eintippst!
Re: rm -r * nicht erlauben
Du könntest mit einem alias arbeiten, z.B. alias rm='rm -i'.
Re: rm -r * nicht erlauben
Die Frage haben sich überraschenderweise schon andere gestellt:
https://serverfault.com/questions/33708 ... es#tab-top
https://serverfault.com/questions/33708 ... es#tab-top
Re: rm -r * nicht erlauben
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.Tintom hat geschrieben:12.04.2018 18:27:56Du könntest mit einem alias arbeiten, z.B. alias rm='rm -i'.
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.
Use ed once in a while!
Re: rm -r * nicht erlauben
Dass das funktioniert ist natürlich im konkreten Fall schön, aber ich finde es konzeptuell hässlich.Meillo hat geschrieben:12.04.2018 19:25:38Der Tipp mit der `-i'-Datei in tobos Link ist hilfreicher, weil der nur selektiv `-i' aktiviert.
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.
Re: rm -r * nicht erlauben
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.
![Wink ;-)](./images/smilies/icon_wink.gif)
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.
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.Ich finde, Dateinamen sollten grundsätzlich nicht zu Parametern expandierbar sein.* Dass es doch geht, scheint mir fast einen Bugreport wert.
Wenn du explizit trennen willst, dann verwende `--' (bei den Programmen, die das unterstuetzen).
Zuletzt geändert von Meillo am 13.04.2018 09:13:34, insgesamt 1-mal geändert.
Grund: s/saverm/safe-rm/
Grund: s/saverm/safe-rm/
Use ed once in a while!
Re: rm -r * nicht erlauben
Ich hatte an deiner Aussage nichts auszusetzen, weder an deren Inhalt noch an der Klarheit.Meillo hat geschrieben:12.04.2018 22:29:57Ich 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.)
Mir ging es um den Sachverhalt an sich.
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.Meillo hat geschrieben:12.04.2018 22:29:57Es 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.
![Wink ;)](./images/smilies/icon_wink.gif)
-
- Beiträge: 507
- Registriert: 30.12.2016 23:48:51
Re: rm -r * nicht erlauben
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.
Re: rm -r * nicht erlauben
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:hikaru hat geschrieben:12.04.2018 23:54:35Da 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.Meillo hat geschrieben:12.04.2018 22:29:57Es 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.![]()
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:
Wie man sieht ist dort auch `--' als Trenner festgelegt. So arbeitet auch getopt(3):http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02 hat geschrieben: 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.
http://pubs.opengroup.org/onlinepubs/96 ... etopt.html
GNU/Linux getopt(3) kann und macht mehr. Es erlaubt auch Abweichungen von der Guideline 9:
(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.)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.
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.
Use ed once in a while!
Re: rm -r * nicht erlauben
@breakthewall: Hervorragender Beitrag! Das ist die korrekte technische Loesung.
Use ed once in a while!
-
- Beiträge: 507
- Registriert: 30.12.2016 23:48:51
Re: rm -r * nicht erlauben
@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.
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.