Der Benutzer hat das Stammverzeichnis in das Unterverzeichnis verschoben oder versucht, den Computer nicht zu reagieren

716
monkeymatrix

Ein besonders spezieller Benutzer von mir hat versehentlich einen Befehl ausgeführt, um Dateien zu verschieben, die ungefähr so ​​aussehen:

mv /* /home/ubuntu/GS14K/ 

Dies führte zu einer Reihe von Fehlern:

mv: kann sich nicht bewegen /bin' to/ home / ubuntu / GS14K / bin ': Berechtigung abgelehnt

mv: /boot' to/ home / ubuntu / GS14K / boot kann nicht verschoben werden : Berechtigung abgelehnt

mv: kann sich nicht bewegen /dev' to/ home / ubuntu / GS14K / dev ': Berechtigung verweigert

wie Sie hoffen, aber dann ist dieser Fehler aufgetreten:

mv: /mnt' to/ home / ubuntu / GS14K / mnt ' kann nicht verschoben werden : Gerät oder Ressource beschäftigt

mv: /proc' to/ home / ubuntu / GS14K / proc kann nicht verschoben werden : Gerät oder Ressource beschäftigt

SSH hörte dann auf zu arbeiten und er konnte nicht wieder rein. Ich kann auch nicht und ich kann nicht auf die Box zugreifen.

Es ist eine AWS-VM, also habe ich einen Stopp erzwungen und einen Neustart durchgeführt, aber die Maschine wird nicht wieder hochgefahren. Ich erkenne an, dass die Maschine wahrscheinlich tot ist, aber ich möchte wissen, was die Ursache sein könnte.

Edit: Ich habe dies auf Ububtu ausgeführt, und der Benutzer hatte zu diesem Zeitpunkt noch kein root, also bin ich neugierig, wie er diesen Befehl ausführen könnte, um so etwas überhaupt zu tun.

2
Hatte dieser Benutzer root-Rechte? Ein Benutzer ohne Rootberechtigung sollte keine störenden Änderungen verursachen können. Wenn Sie Daten von der Maschine benötigen und es sich um eine von EBS unterstützte Instanz handelt, können Sie das Speichergerät mit einer anderen VM verbinden und auf diese Weise wiederherstellen. qasdfdsaq vor 9 Jahren 0
Danke, und das ist es, was ich letztendlich getan habe. Der Benutzer hatte kein root, also bin ich überrascht, dass er sich genauso bewegen konnte wie er. Wenn Sie das angehängte Laufwerk / home / betrachten, werden jetzt Systemordner komplett durcheinander gebracht. monkeymatrix vor 9 Jahren 0
+1 für den Ausdruck * ein besonderer Benutzer von mir *. Du bist wirklich der verzeihende Typ. MariusMatutiae vor 9 Jahren 1
Ohne Root-Zugriff (oder Zugriff auf Root über Sudo) hätte der Benutzer keine Dateien unter `/` verschieben können. Sind Sie zu 100% sicher, dass sie keinen solchen Zugang haben? Dies setzt natürlich voraus, dass Sie keine Systemdateien mit ungeraden Berechtigungen hatten (z. B. Schreibzugriff für Benutzer ohne Rootberechtigung) ... mjturner vor 9 Jahren 0

2 Antworten auf die Frage

2
ukesh upendran

Wenn das Boot-Gerät eine Festplatte ist, erwartet das BIOS, dass der Bootloader im MBR Ihrer Festplatte vorhanden ist. Dieser versucht, den Kernel von dem in der Bootloader-Konfiguration angegebenen Gerätestandort zu laden. Wahrscheinlich ist dies / boot / kernel-image. Nachdem Sie alles nach / home / verschoben haben, kann der Bootloader das Kernel-Image nicht mehr finden. Auch im Fall von grub wird der Bootloader in 2 Stufen geladen, die erste Stufe wird in MBR und die zweite wird erneut an einem Gerätestandort angegeben. Daher besteht eine gute Chance, dass auch die 2. Stufe des Bootloaders nicht ausgeführt wird Belastung

Sie könnten hier mehr lesen

Sie haben recht, aber es bedarf einer besseren Erklärung. MBR oder EFS werden durch den eingegebenen Befehl nicht verschoben, und der Kernel wurde nicht verschoben. Ich vermute, / etc / grub wurde verschoben. Daher funktioniert der GRUB-Lader für die 2. Stufe nicht, da er das erforderliche nicht findet Konfigurationsdateien. Sie können versuchen, den Computer über ein Netzwerk zu starten oder eine Livedvd zu verwenden, um Grub mithilfe der Bootreparatur zu reparieren. Ich vermute, dass Sie das schon probiert haben und es hat nicht funktioniert. Beachten Sie, dass / etc / auch die Nvram-Daten enthält, daher ist es äußerst wichtig. Überprüfen Sie das einmal. Tamoghna Chowdhury vor 9 Jahren 0
Vielen Dank für diese Erklärung, @ TamoghnaChowdhury. Ich wollte nicht, dass MBR oder EFS umgesiedelt werden. Der Kernel befindet sich im Boot-Gerät (in diesem Fall Diskette), damit der Bootloader in den Arbeitsspeicher geladen werden kann. Wenn der Bootloader grub ist, enthält grub.cfg die Informationen über die Liste der zu ladenden Kernel und den Speicherort jedes Kernels. Standardmäßig befindet sich der Speicherort des Kernels unter / boot, sodass der Bootloader den komprimierten Kernel in den Arbeitsspeicher laden und dekomprimieren kann (wiederum sind dies alle arch-abhängig). ukesh upendran vor 9 Jahren 0
Kann dies mit einem Benutzer erreicht werden, der nicht über root verfügt? monkeymatrix vor 9 Jahren 2
@monkeymatrix Nach dem Prinzip, nein, sollte es nicht. Probieren Sie es einfach selbst aus: Versuchen Sie, als normaler Benutzer jeden Befehl aus, z. B. / bin, zu entfernen, und Sie werden von Permisison verweigert. Dies gilt sowohl für das Booten von ile als auch für reguläre Befehle. MariusMatutiae vor 9 Jahren 0
0
Dmitry Grigoryev

Da der Computer vor dem Neustart nicht mehr reagierte, bin ich nicht überzeugt, dass das Kernel-Image durch Verschieben die Ursache war. Benutzer sollen von vornherein keinen Zugriff auf diese Datei haben, ansonsten ist die gesamte Systemsicherheit gefährdet: Erstellen Sie einfach ein gepatchtes Kernel-Image, das Ihnen root-Zugriff gibt, wenn Sie wait4 () aufrufen und neu starten .

Könnte dieser spezielle Benutzer sich permanent auf einige Systemkonfigurationsdateien zugreifen /etc? Wenn Sie einige davon entfernen, kann der Startvorgang leicht unterbrochen und das laufende System beschädigt werden.

Ohne Details ist es schwierig, eine genauere Antwort zu geben. Wenn Sie beispielsweise "SSH nicht mehr funktionieren" sagen, meinen Sie, dass die aktive Sitzung zwangsweise geschlossen wurde, oder hat sich der Benutzer abgemeldet und versucht, sich erneut anzumelden? Und wenn Sie sagen "Die Maschine kommt nicht zurück", was passiert genau? Irgendwelche Meldungen auf der Konsole oder gar nichts?

Letztendlich müssen Sie das Dateisystem untersuchen, um festzustellen, welche Dateien fehlen. Es kann keine offizielle Quelle geben, die besagt, wie genau ein bestimmter Benutzer sich selbst in den Fuß geschossen hat.