rm -r * nicht erlauben

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
ubik
Beiträge: 145
Registriert: 26.02.2009 12:02:24

rm -r * nicht erlauben

Beitrag von ubik » 12.04.2018 18:09:45

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?

Benutzeravatar
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

Beitrag von slughorn » 12.04.2018 18:26:54

Indem Du den Befehl gar nicht erst eintippst!

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: rm -r * nicht erlauben

Beitrag von Tintom » 12.04.2018 18:27:56

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

tobo
Beiträge: 1964
Registriert: 10.12.2008 10:51:41

Re: rm -r * nicht erlauben

Beitrag von tobo » 12.04.2018 18:46:50

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

Benutzeravatar
Meillo
Moderator
Beiträge: 8782
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: rm -r * nicht erlauben

Beitrag von Meillo » 12.04.2018 19:25:38

Tintom hat geschrieben: ↑ zum Beitrag ↑
12.04.2018 18:27:56
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.
Use ed once in a while!

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: rm -r * nicht erlauben

Beitrag von hikaru » 12.04.2018 20:41:12

Meillo hat geschrieben: ↑ zum Beitrag ↑
12.04.2018 19:25:38
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.

Benutzeravatar
Meillo
Moderator
Beiträge: 8782
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: rm -r * nicht erlauben

Beitrag von Meillo » 12.04.2018 22:29:57

hikaru hat geschrieben: ↑ zum Beitrag ↑
12.04.2018 20:41:12
Meillo hat geschrieben: ↑ zum Beitrag ↑
12.04.2018 19:25:38
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).
Zuletzt geändert von Meillo am 13.04.2018 09:13:34, insgesamt 1-mal geändert.
Grund: s/saverm/safe-rm/
Use ed once in a while!

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: rm -r * nicht erlauben

Beitrag von hikaru » 12.04.2018 23:54:35

Meillo hat geschrieben: ↑ zum Beitrag ↑
12.04.2018 22:29:57
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.
Meillo hat geschrieben: ↑ zum Beitrag ↑
12.04.2018 22:29:57
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
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: rm -r * nicht erlauben

Beitrag von breakthewall » 13.04.2018 02:46:29

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.

Benutzeravatar
Meillo
Moderator
Beiträge: 8782
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: rm -r * nicht erlauben

Beitrag von Meillo » 13.04.2018 10:09:25

hikaru hat geschrieben: ↑ zum Beitrag ↑
12.04.2018 23:54:35
Meillo hat geschrieben: ↑ zum Beitrag ↑
12.04.2018 22:29:57
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:
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.
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.
Use ed once in a while!

Benutzeravatar
Meillo
Moderator
Beiträge: 8782
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: rm -r * nicht erlauben

Beitrag von Meillo » 13.04.2018 10:13:23

@breakthewall: Hervorragender Beitrag! Das ist die korrekte technische Loesung.
Use ed once in a while!

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: rm -r * nicht erlauben

Beitrag von breakthewall » 13.04.2018 22:14:45

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

Antworten