Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.security.misc > #40930 > unrolled thread

Editieren als root

Back to article view | Back to de.comp.security.misc

Contents

  Editieren als root Alexander Goetzenstein <alexander_goetzenstein@web.de> - 2026-01-29 14:52 +0100
    Re: Editieren als root Ralph Aichinger <ra@h5.or.at> - 2026-01-29 14:16 +0000
      Re: Editieren als root Matthias Gerds <m.gerds@posteo.de> - 2026-01-29 17:56 +0100
        Re: Editieren als root Alexander Goetzenstein <alexander_goetzenstein@web.de> - 2026-01-30 12:08 +0100
          Re: Editieren als root Arno Welzel <usenet@arnowelzel.de> - 2026-02-09 11:45 +0100
      Re: Editieren als root Alexander Goetzenstein <alexander_goetzenstein@web.de> - 2026-01-30 12:07 +0100
        Re: Editieren als root Ralph Aichinger <ra@h5.or.at> - 2026-01-30 15:19 +0000
          Re: Editieren als root Udo Steinbach <trashcan@udoline.de> - 2026-02-04 11:41 +0100
            Re: Editieren als root Marc Haber <mh+usenetspam1118@zugschl.us> - 2026-02-04 22:55 +0100
            Re: Editieren als root Stefan Reuther <stefan.news@arcor.de> - 2026-02-05 18:49 +0100
              Re: Editieren als root Marc Haber <mh+usenetspam1118@zugschl.us> - 2026-02-07 10:45 +0100
                Re: Editieren als root Stefan Reuther <stefan.news@arcor.de> - 2026-02-09 18:05 +0100
            Re: Editieren als root hauke+usenet@causeuse.org (Hauke Fath) - 2026-03-22 14:18 +0100
              Re: Editieren als root Alf der Kleine <gogoki5126@cgbird.com> - 2026-03-22 16:10 +0100
                Re: Editieren als root Helmut Waitzmann <nn.throttle@erine.email> - 2026-03-22 21:41 +0100
                  Re: Editieren als root Alf der Kleine <gogoki5126@cgbird.com> - 2026-03-23 09:49 +0100
                    alias rm='rm -i' (was: Editieren als root) Helmut Waitzmann <nn.throttle@erine.email> - 2026-03-24 00:46 +0100
                      Re: alias rm='rm -i' (was: Editieren als root) Marc Haber <mh+usenetspam1118@zugschl.us> - 2026-03-24 07:20 +0100
                Re: Editieren als root hauke+usenet@causeuse.org (Hauke Fath) - 2026-05-10 16:21 +0200
                  Re: Editieren als root Axel Reichert <mail@axel-reichert.de> - 2026-05-11 11:14 +0200
                    Re: Editieren als root Michael Pachta <mipani@gmx.de> - 2026-05-11 11:49 +0200
                      Re: Editieren als root Holger Schieferdecker <spamless@gmx.de> - 2026-05-11 12:12 +0200
                        Re: Editieren als root Michael Pachta <mipani@gmx.de> - 2026-05-11 13:42 +0200
                          Re: Editieren als root Axel Reichert <mail@axel-reichert.de> - 2026-05-11 15:14 +0200
                            Re: Editieren als root Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-05-11 17:26 +0200
                              Re: Editieren als root Michael Pachta <mipani@gmx.de> - 2026-05-12 10:08 +0200
                                Re: Editieren als root Ralph Aichinger <ra@h5.or.at> - 2026-05-12 09:12 +0000
                                  Re: Editieren als root Michael Pachta <mipani@gmx.de> - 2026-05-12 12:54 +0200
                                  Re: Editieren als root Joerg Walther <joerg.walther@magenta.de> - 2026-05-12 15:02 +0200
                    Re: Editieren als root Ralph Aichinger <ra@h5.or.at> - 2026-05-11 11:27 +0000
                    Re: Editieren als root Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-05-11 15:28 +0200
                      Re: Editieren als root Axel Reichert <mail@axel-reichert.de> - 2026-05-11 16:20 +0200
                        Re: Editieren als root Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-05-11 17:28 +0200
                    Re: Editieren als root Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-05-11 15:34 +0200
                      Re: Editieren als root "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-11 18:52 +0200
                  Re: Editieren als root Stefan Reuther <stefan.news@arcor.de> - 2026-05-11 18:13 +0200
                    Re: Editieren als root Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-05-11 22:40 +0200
                    Re: Editieren als root Ralph Aichinger <ra@h5.or.at> - 2026-05-12 04:59 +0000
                    Re: Editieren als root Christian Weisgerber <naddy@mips.inka.de> - 2026-05-12 13:56 +0000
                      Re: Editieren als root "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-12 18:13 +0200
        Re: Editieren als root Stefan Reuther <stefan.news@arcor.de> - 2026-01-31 10:12 +0100
    Re: Editieren als root Thomas Hochstein <thh@thh.name> - 2026-01-29 19:32 +0100
      Re: Editieren als root Alexander Goetzenstein <alexander_goetzenstein@web.de> - 2026-01-30 12:13 +0100
        Re: Editieren als root Lutz Falke <lutzfalke@gmx.de> - 2026-01-30 11:36 +0000
      Re: Editieren als root "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-01-30 18:06 +0100
        Re: Editieren als root Thomas Hochstein <thh@thh.name> - 2026-01-30 19:25 +0100
        Re: Editieren als root Ralph Aichinger <ra@h5.or.at> - 2026-01-30 18:55 +0000
    Re: Editieren als root Helmut Waitzmann <nn.throttle@erine.email> - 2026-02-05 10:29 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#41367

Am 11.05.2026 um 11:14 schrieb Axel Reichert:
> Hatte einen Kollegen, der sich mit "rm -i" immer wieder ins Knie
> geschossen hat. 

Inwiefern? rm -i fragt vor jedem Löschvorgang nach. Kann beim Löschen 
vieler Dateien natürlich nervig sein.

> Dummerweise schaufelte das keinen Plattenplatz frei, so dass die
> Katastrophe dann spaeter beim "rm -rf ~/my-trash" auftrat.

Der obige Befehl löscht das Verzeichnis ~/my-trash rekursiv und ohne 
Nachfrage, also das, was der Benutzer offenbar wollte. Oder was wollte 
er eigentlich erreichen? Anscheinend stehe ich auf dem Schlauch.

[toc] | [prev] | [next] | [standalone]

#41368

Am 11.05.2026 um 11:49 schrieb Michael Pachta:
> Am 11.05.2026 um 11:14 schrieb Axel Reichert:
>> Dummerweise schaufelte das keinen Plattenplatz frei, so dass die
>> Katastrophe dann spaeter beim "rm -rf ~/my-trash" auftrat.
> 
> Der obige Befehl löscht das Verzeichnis ~/my-trash rekursiv und ohne 
> Nachfrage, also das, was der Benutzer offenbar wollte. Oder was wollte 
> er eigentlich erreichen? Anscheinend stehe ich auf dem Schlauch.

Vielleicht liegt die Lösung in dem, was Du nicht zitiert hast. Ich 
meine, das kann man so interpretieren, daß rm durch ein gleichnamiges 
Skript ersetzt wurde, das nicht löscht, sondern nur verschiebt. Wenn man 
auf die Art aber das Verzeichnis löschen will, das die verschobenen 
Dateien enthält, werden die ja nur wieder dort hinein verschoben...

Holger

[toc] | [prev] | [next] | [standalone]

#41370

Am 11.05.2026 um 12:12 schrieb Holger Schieferdecker:
> Am 11.05.2026 um 11:49 schrieb Michael Pachta:
>> Am 11.05.2026 um 11:14 schrieb Axel Reichert:
>>> Dummerweise schaufelte das keinen Plattenplatz frei, so dass die
>>> Katastrophe dann spaeter beim "rm -rf ~/my-trash" auftrat.
>>
>> Der obige Befehl löscht das Verzeichnis ~/my-trash rekursiv und ohne 
>> Nachfrage, also das, was der Benutzer offenbar wollte. Oder was wollte 
>> er eigentlich erreichen? Anscheinend stehe ich auf dem Schlauch.
> 
> Vielleicht liegt die Lösung in dem, was Du nicht zitiert hast. Ich 
> meine, das kann man so interpretieren, daß rm durch ein gleichnamiges 
> Skript ersetzt wurde, das nicht löscht, sondern nur verschiebt. Wenn man 
> auf die Art aber das Verzeichnis löschen will, das die verschobenen 
> Dateien enthält, werden die ja nur wieder dort hinein verschoben...

Ah, danke, das ergibt Sinn. Wenn ich das richtig verstehe, dann machte 
der obige rm-Befehl bei dem besagten User folgendes:
mv ~/my-trash ~/my-trash
Aufgrund des rekursiven Aufrufs sind die Datenmengen aber immer größer 
geworden und ein Abbruch erfolgte dann erst bei "disk full".

[toc] | [prev] | [next] | [standalone]

#41371

Michael Pachta <mipani@gmx.de> writes:

>>> Am 11.05.2026 um 11:14 schrieb Axel Reichert:
>>>> Dummerweise schaufelte das keinen Plattenplatz frei, so dass die
>>>> Katastrophe dann spaeter beim "rm -rf ~/my-trash" auftrat.
>>>
>>> Der obige Befehl löscht das Verzeichnis ~/my-trash rekursiv und
>>> ohne Nachfrage, also das, was der Benutzer offenbar wollte. Oder
>>> was wollte er eigentlich erreichen? Anscheinend stehe ich auf dem
>>> Schlauch.
>> Vielleicht liegt die Lösung in dem, was Du nicht zitiert hast. Ich
>> meine, das kann man so interpretieren, daß rm durch ein
>> gleichnamiges Skript ersetzt wurde, das nicht löscht, sondern nur
>> verschiebt. Wenn man auf die Art aber das Verzeichnis löschen will,
>> das die verschobenen Dateien enthält, werden die ja nur wieder dort
>> hinein verschoben...
>
> Ah, danke, das ergibt Sinn. Wenn ich das richtig verstehe, dann machte
> der obige rm-Befehl bei dem besagten User folgendes:
> mv ~/my-trash ~/my-trash
> Aufgrund des rekursiven Aufrufs sind die Datenmengen aber immer größer
> geworden und ein Abbruch erfolgte dann erst bei "disk full".

Vermutlich lief es anders, ist aber gut 25 Jahre her, so dass ich die
Details der Aliase/Shellskripte nicht mehr parat habe. Wenn die Platte
volllief (wir hatten damals ziemlich grosse Datenmengen produziert) und
der Kollege aufraeumen wollte, kam wahrscheinlich ein

  \rm -rf ~/my-trash

o. ae. zum Einsatz, was den Alias umgangen hat und daher brav alles
loeschte. Und danach fiel ihm ein, dass dort ja noch wertvolle Daten
gewesen waeren ...

Tschoe!

Axel

[toc] | [prev] | [next] | [standalone]

#41375

Axel Reichert <mail@axel-reichert.de> wrote:
>Vermutlich lief es anders, ist aber gut 25 Jahre her, so dass ich die
>Details der Aliase/Shellskripte nicht mehr parat habe. Wenn die Platte
>volllief (wir hatten damals ziemlich grosse Datenmengen produziert) und
>der Kollege aufraeumen wollte, kam wahrscheinlich ein
>
>  \rm -rf ~/my-trash
>
>o. ae. zum Einsatz, was den Alias umgangen hat und daher brav alles
>loeschte. Und danach fiel ihm ein, dass dort ja noch wertvolle Daten
>gewesen waeren ...

Das einnert mich an den DAU, der besonders wichtige Mails im
"Papierkorb" eines mit Kollegen geteilten Mailpostfachs aufbewahrte
und ein Kollege dann auf "Papierkorb leeren" klickte.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#41381

Am 11.05.2026 um 17:26 schrieb Marc Haber:
> Das einnert mich an den DAU, der besonders wichtige Mails im 
> "Papierkorb" eines mit Kollegen geteilten Mailpostfachs aufbewahrte 
> und ein Kollege dann auf "Papierkorb leeren" klickte.

Vor wenigen Tagen erst äußerte sich nebenan, in
de.comp.software.mozilla.mailnews, ein "Experte", der irgendwelche 
"Daten" ins Usenet "sichert".

Zitat aus <0_EKR.48214$6t9.22041@fx15.ams4>
> Vielleicht hängt es damit zusammen, dass seit etwa einem Jahr im
> Usenet sehr viele Beiträge verschwinden. Anfangs betraf das
> vorwiegend welche, die 2 oder 3 Jahre alt waren. Der Rest schien
> nicht betroffen. Vor ein paar Tagen habe ich aber einen gesucht, der
> 10 Jahre alt war, und er war weg. Das ist für mich fatal, weil ich
> meine Daten ins Usenet sichere, natürlich verschlüsselt und mit
> kryptischem Header.

Da kann man sich nur noch an den Kopf fassen.

[toc] | [prev] | [next] | [standalone]

#41382

Michael Pachta <mipani@gmx.de> wrote:
> Vor wenigen Tagen erst äußerte sich nebenan, in
> de.comp.software.mozilla.mailnews, ein "Experte", der irgendwelche 
> "Daten" ins Usenet "sichert".

Ich kenne die Story des Posters und etwas mehr Kontext (es geht 
IIRC um aufgezeichnete Fernsehfolgen, also nicht sowas wie
die eigene Buchhaltung oder Fotos). Ja es mag exzentrisch sein,
aber es ist nicht so völlig irrational wie du es jetzt hinstellst.
Der Poster hat das IIRC so in der Größenordnung einer niedrigen
zweistelligen TB-Datenmenge an alten Folgen irgendwelcher deutscher
Fernsehserien.

Ich hab früher auch vom Sat sachen aufgezeichnet und davon 
kein Backup gehabt. Wenn es weg war war es halt weg. 

Ihm ist das Zeug vermutlich wichtiger, aber man kann
die Kirche im Dorf lassen.

/ralph

[toc] | [prev] | [next] | [standalone]

#41383

Am 12.05.2026 um 11:12 schrieb Ralph Aichinger:
> Ich kenne die Story des Posters und etwas mehr Kontext (es geht
> IIRC um aufgezeichnete Fernsehfolgen, also nicht sowas wie
> die eigene Buchhaltung oder Fotos). Ja es mag exzentrisch sein,
> aber es ist nicht so völlig irrational wie du es jetzt hinstellst.

Na ja, das Ende vom Lied war, dass seine "Daten", die er im Thread aber 
nicht weiter spezifiziert hat, nun weg sind. Für ihn ist das "fatal", 
wie er schreibt. Ich kann nichts rationales daran erkennen. Merkspruch: 
Ist es nicht mein Server, dann sind es auch nicht meine Daten.

> Der Poster hat das IIRC so in der Größenordnung einer niedrigen
> zweistelligen TB-Datenmenge an alten Folgen irgendwelcher deutscher
> Fernsehserien.

Es ist egal, was für Daten das sind. Sie sind weg.

> Ich hab früher auch vom Sat sachen aufgezeichnet und davon
> kein Backup gehabt. Wenn es weg war war es halt weg.

Dann waren die Daten auch nicht wichtig, was völlig legitim ist. Ich 
habe auch irgendwo Aufzeichnungen alter TV-Sendungen (auf irgendwelchen 
alten HDDs), die ich nicht weiter gesichert habe. Wenn weg, dann weg.

[toc] | [prev] | [next] | [standalone]

#41384

Ralph Aichinger wrote:

>Der Poster hat das IIRC so in der Größenordnung einer niedrigen
>zweistelligen TB-Datenmenge an alten Folgen irgendwelcher deutscher
>Fernsehserien.

130TB derzeit, das kriegt man außer im Usenet nicht bezahlbar in eine
Cloud. Angesichts der Vorhaltezeit des verwendeten Servers von weit über
10 Jahren (Easynews) eigentlich gar keine so schlechte Idee, imho. Er
hatte wohl mal einen Plattenausfall und konnte den Platteninhalt
innerhalb von 3 Tagen wiederherstellen.

-jw-
-- 
And now for something completely different...

[toc] | [prev] | [next] | [standalone]

#41369

Axel Reichert <mail@axel-reichert.de> wrote:
> Hatte einen Kollegen, der sich mit "rm -i" immer wieder ins Knie
> geschossen hat. Seine naechste Ausbaustufe waren rm-Shellskripte, die
> nicht geloescht, sondern in versteckte Verzeichnisse verschoben haben.
> Dummerweise schaufelte das keinen Plattenplatz frei, so dass die
> Katastrophe dann spaeter beim "rm -rf ~/my-trash" auftrat.
> 
> Irgendwann hatte ich ihm, halb mitfuehlend, halb belustigt, empfohlen,
> es doch bei "the real thing", dem echten "rm" ohne Netz und doppelten
> Boden, zu belassen. Und seitdem war Ruhe.
> 
> Peltzman-Effekt, siehe
> 
>   https://de.wikipedia.org/wiki/Risikokompensation

Ja. Die sinnvollste Variante damit umzugehen ist IMHO ein
Backup. Denn das braucht man sowieso, wenn die Platte
eingeht oder Malware sich einschleicht.

/ralph

[toc] | [prev] | [next] | [standalone]

#41372

Axel Reichert <mail@axel-reichert.de> wrote:
>Hatte einen Kollegen, der sich mit "rm -i" immer wieder ins Knie
>geschossen hat.

Du meins mit alias rm=rm -i? Sowas würde ich höchstens als rmi
zulsasen, dan fallen die daran gewöhnten Leute wenigstens bei Fehlen
des Alias nicht auf die Nase.

> Seine naechste Ausbaustufe waren rm-Shellskripte, die
>nicht geloescht, sondern in versteckte Verzeichnisse verschoben haben.

Framstag hat diese Rad doch auch erfinden.

>Dummerweise schaufelte das keinen Plattenplatz frei, so dass die
>Katastrophe dann spaeter beim "rm -rf ~/my-trash" auftrat.

Das Skript hatt keinen Specialcase wenn das Trashverzeichnis gelöscht
werden soll?

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#41374

Marc Haber <mh+usenetspam2616@zugschl.us> writes:

> Axel Reichert <mail@axel-reichert.de> wrote:
>>Hatte einen Kollegen, der sich mit "rm -i" immer wieder ins Knie
>>geschossen hat.
>
> Du meins mit alias rm=rm -i? 

Ja.

> Sowas würde ich höchstens als rmi zulsasen, dan fallen die daran
> gewöhnten Leute wenigstens bei Fehlen des Alias nicht auf die Nase.

War sein eigener Alias, nicht systemweit definiert. Er wollte sich ja
vor "rm" schuetzen. Wenn er ein Problem damit hatte, vor dem Abschicken
des Kommandos nochmal gruendlich nachzudenken, ob das sinnvoll ist,
haette er vermutlich auch ein Problem damit gehabt, sich vor dem
Eingeben von "rm" zu erinnern, dass er eigentlich "rmi" nehmen
sollte/wollte. Daher kann ich das Uebersteuern von "rm" verstehen.

>>Dummerweise schaufelte das keinen Plattenplatz frei, so dass die
>>Katastrophe dann spaeter beim "rm -rf ~/my-trash" auftrat.
>
> Das Skript hatt keinen Specialcase wenn das Trashverzeichnis gelöscht
> werden soll?

Noe. Wir waren als Ingenieure mit numerischer Simulation befasst, nicht
mit dem Schreiben narrensicherer (uns inklusive) Shellskripte. Koennte
sogar noch csh oder tcsh auf IRIX gewesen sein.

Tschoe!

Axel

[toc] | [prev] | [next] | [standalone]

#41376

Axel Reichert <mail@axel-reichert.de> wrote:
>Marc Haber <mh+usenetspam2616@zugschl.us> writes:
>> Sowas würde ich höchstens als rmi zulsasen, dan fallen die daran
>> gewöhnten Leute wenigstens bei Fehlen des Alias nicht auf die Nase.
>
>War sein eigener Alias, nicht systemweit definiert. Er wollte sich ja
>vor "rm" schuetzen. Wenn er ein Problem damit hatte, vor dem Abschicken
>des Kommandos nochmal gruendlich nachzudenken, ob das sinnvoll ist,
>haette er vermutlich auch ein Problem damit gehabt, sich vor dem
>Eingeben von "rm" zu erinnern, dass er eigentlich "rmi" nehmen
>sollte/wollte. Daher kann ich das Uebersteuern von "rm" verstehen.

Die psychologische Idee ist, das "rmi" in das Fingermemory zu
bekommen, damit "rm" ohne "i" ein Ausnahmezustand wird.

Bei mir kommt bei "ls" automatisch ein "-al" hinterher. Das
wegzulassen braucht Willensstärke.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#41373

Axel Reichert <mail@axel-reichert.de> wrote:
>Dummerweise schaufelte das keinen Plattenplatz frei, so dass die
>Katastrophe dann spaeter beim "rm -rf ~/my-trash" auftrat.

Das ist übrigens auch der Nachteil von snapper und anderen Mechanismen
die regelmäßige btrfs- oder ZFS-Snapshots vom Home machen: Löschen von
Dateien macht keinen Plattenplatz frei, wenn man die Snapshots als
Readonly macht muss man auch darauf warten bis der ganze Snapshot weg
geht.

Gibt es Dateisysteme, die Dateien mit > 100 MB oder mit einem
speziellen xattr von Snapshots ausnehmen können?

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#41378

On 2026-05-11 15:34, Marc Haber <mh+usenetspam2616@zugschl.us> wrote:
> Das ist übrigens auch der Nachteil von snapper und anderen Mechanismen
> die regelmäßige btrfs- oder ZFS-Snapshots vom Home machen: Löschen von
> Dateien macht keinen Plattenplatz frei, wenn man die Snapshots als
> Readonly macht muss man auch darauf warten bis der ganze Snapshot weg
> geht.

Man könnte jeweils den ältesten Snapshot (außer eventuell die letzten
$n) löschen, wenn der freie Platz unter eine bestimmte Schwelle fällt.


> Gibt es Dateisysteme, die Dateien mit > 100 MB oder mit einem
> speziellen xattr von Snapshots ausnehmen können?

Die müssten dann aber deutlich anders arbeiten als bei den
CoW-Filesystemen und es erscheint mir schwierig, da Atomizität erreichen
zu können.

        hjp

[toc] | [prev] | [next] | [standalone]

#41377

Am 10.05.2026 um 16:21 schrieb Hauke Fath:
>>> alias rm "rm -i"
>>> alias mv "mv -i"
>>> alias cp "cp -i"
[...]
> Es verdummt.
> 
> Wer einmal als root mit 'rm * ~' /etc ausgeräumt hat, schaut den Rest
> des Lebens genau hin, statt wie im GUI Warnungen mechanisch zu
> bestätigen, bevor man sie sinnentnehmend gelesen hat.

Du lässt deine Stromleitungen unisoliert ("wer einmal an 220V gelangt
hat, schaut den Rest des Lebens genau hin"), und deine Kreissäge offen
("wer einmal ins Sägeblatt gelangt hat, schaut den Rest des lebens genau
hin")? Wäre sonst inkonsistent.

Ich find's jetzt nicht verwerflich, sich in seinem persönlichen System
Sicherheitsmechanismen zu geben. Dafür gibt's die Möglichkeit ja.


  Stefan

[toc] | [prev] | [next] | [standalone]

#41379

Stefan Reuther <stefan.news@arcor.de> wrote:
>Am 10.05.2026 um 16:21 schrieb Hauke Fath:
>>>> alias rm "rm -i"
>>>> alias mv "mv -i"
>>>> alias cp "cp -i"
>[...]
>> Es verdummt.
>> 
>> Wer einmal als root mit 'rm * ~' /etc ausgeräumt hat, schaut den Rest
>> des Lebens genau hin, statt wie im GUI Warnungen mechanisch zu
>> bestätigen, bevor man sie sinnentnehmend gelesen hat.
>
>Du lässt deine Stromleitungen unisoliert ("wer einmal an 220V gelangt
>hat, schaut den Rest des Lebens genau hin"), und deine Kreissäge offen
>("wer einmal ins Sägeblatt gelangt hat, schaut den Rest des lebens genau
>hin")? Wäre sonst inkonsistent.
>
>Ich find's jetzt nicht verwerflich, sich in seinem persönlichen System
>Sicherheitsmechanismen zu geben. Dafür gibt's die Möglichkeit ja.

So lange man nur auf diesem persönlichen System arbeitet, geschenkt.
Wenn man auf verschiedenen Systemen arbeitet und sich gewisse Accounts
mit anderen teilt¹, ist die Gewöhnung an die eigenen
Spezialmechanismen brandgefährlich.

Grüße
Marc

¹ es gibt ja Firmen die persönliche Accounts für die achse des Bösen
halten und sich jeder als root einloggt
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#41380

Stefan Reuther <stefan.news@arcor.de> wrote:
> Du lässt deine Stromleitungen unisoliert ("wer einmal an 220V gelangt
> hat, schaut den Rest des Lebens genau hin"), und deine Kreissäge offen
> ("wer einmal ins Sägeblatt gelangt hat, schaut den Rest des lebens genau
> hin")? Wäre sonst inkonsistent.

Nein, der Unterschied: Alle anderen Leute haben die Stromleitungen eben
auch nicht unisoliert und ihre Sägen ohne Schutz.

/ralph

[toc] | [prev] | [next] | [standalone]

#41385

On 2026-05-11, Stefan Reuther <stefan.news@arcor.de> wrote:

[alias rm='rm -i']
> Du lässt deine Stromleitungen unisoliert ("wer einmal an 220V gelangt
> hat, schaut den Rest des Lebens genau hin"), und deine Kreissäge offen
> ("wer einmal ins Sägeblatt gelangt hat, schaut den Rest des lebens genau
> hin")? Wäre sonst inkonsistent.

Der Vergleich wäre angebracht, wenn es einen häufigen Befehl "mr"
oder so gäbe, so dass man "rm" versehentlich wegen eines Tippfehlers
aufrufen könnte. In der Praxis erreicht man "rm" aber nicht aus
Versehen.

> Ich find's jetzt nicht verwerflich, sich in seinem persönlichen System
> Sicherheitsmechanismen zu geben. Dafür gibt's die Möglichkeit ja.

Sicher.

Ich halte rm='rm -i' trotzdem nicht für sinnvoll. Erstens löscht
man alle naslang Dinge, so dass schnell der Effekt eintreten wird,
dass man automatisch bestätigt und erst hinterher bemerkt, was man
da bestätigt hat.

Zweitens ist "rm -i" einfach unpraktikabel. Ich jedenfalls lösche
häufig Verzeichnisse mit Dutzenden, Hunderten oder mehr Dateien.
Da müsste man den Alias dann also ohnehin umgehen, sei es mit
angehängtem -f oder besser, indem man die Alias-Auflösung durch
Quoting verhindert, am einfachsten mit \rm.

Wer sich da einen Sicherheitsgurt wünscht, sollte mal in der
rm(1)-Manpage seiner Systeme nachschauen. Manche Implementierungen[1]
haben nämlich eine Option

  -I   Request confirmation once if more than three files are being
       removed or if a directory is being recursively removed.  This is
       a far less intrusive option than -i yet provides almost the same
       level of protection against mistakes.

Ein Alias rm='rm -I' mag individuell sinnvoll sein.


[1] DragonFly (2004-10-06),
    FreeBSD (2004-10-28),
    GNU Coreutils (2006-02-20)
-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#41386

On 2026-05-12 15:56, Christian Weisgerber <naddy@mips.inka.de> wrote:
> On 2026-05-11, Stefan Reuther <stefan.news@arcor.de> wrote:
> [alias rm='rm -i']
>> Du lässt deine Stromleitungen unisoliert ("wer einmal an 220V gelangt
>> hat, schaut den Rest des Lebens genau hin"), und deine Kreissäge offen
>> ("wer einmal ins Sägeblatt gelangt hat, schaut den Rest des lebens genau
>> hin")? Wäre sonst inkonsistent.
>
> Der Vergleich wäre angebracht, wenn es einen häufigen Befehl "mr"
> oder so gäbe, so dass man "rm" versehentlich wegen eines Tippfehlers
> aufrufen könnte. In der Praxis erreicht man "rm" aber nicht aus
> Versehen.

Aber eventuell im falschen Directory. Oder am falschen Host.


>> Ich find's jetzt nicht verwerflich, sich in seinem persönlichen System
>> Sicherheitsmechanismen zu geben. Dafür gibt's die Möglichkeit ja.
>
> Sicher.
>
> Ich halte rm='rm -i' trotzdem nicht für sinnvoll.

ACK. Aus den von Dir genannten Gründen. Und außerdem, weil -i auch nur
dann hilft, wenn das erste File anders heißt als erwartet.

        hjp

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.comp.security.misc

csiph-web