Пользователь переместил корневой каталог в подкаталог или попытался, машина не отвечает

Question

Мой специальный пользователь случайно запустил команду для перемещения файлов, которые выглядели примерно так:

mv /* /home/ubuntu/GS14K/

Это привело к ряду ошибок:

mv: невозможно переместить /bin' to/home/ubuntu/GS14K/bin': разрешение запрещено

mv: невозможно переместить /boot' to/home/ubuntu/GS14K/boot: разрешение запрещено

mv: не может переместиться /dev' to/home/ubuntu/GS14K/dev': в доступе отказано

как можно было бы надеяться, но потом появилась эта ошибка:

mv: невозможно переместить /mnt' to/home/ubuntu/GS14K/mnt': устройство или ресурс занят

mv: невозможно переместить /proc' to/home/ubuntu/GS14K/proc': устройство или ресурс занят

SSH тогда прекратил работать, и он не мог вернуться. Я тоже не могу и не могу получить доступ к коробке.

Это виртуальная машина AWS, поэтому я принудительно остановился и перезагрузился, но машина не вернулась. Я признаю, что машина, вероятно, мертва, но мне интересно знать, в чем причина.

Изменить: я запускал это на Ububtu, и у пользователя не было root в то время, поэтому мне интересно, как он мог выполнить эту команду, чтобы сделать что-то подобное вообще.

Answer 1

Это потому, что если ваше загрузочное устройство является диском, то BIOS ожидает, что загрузчик будет присутствовать в MBR вашего диска, который попытается загрузить ядро из расположения устройства, указанного в конфигурации загрузчика. Скорее всего, это будет /boot /kernel-image, теперь, когда вы переместили все в /home /, загрузчик больше не будет находить образ ядра. Также в случае grub, загрузчик загружается в 2 этапа, первый этап будет в MBR, а второй снова будет указан в расположении устройства, так что есть хороший шанс, что даже 2-й этап загрузчика не будет нагрузка

Вы можете прочитать больше здесь

Answer 2

Поскольку машина перестала отвечать до перезагрузки, я не уверен, что причиной было перемещение образа ядра. Пользователи не должны иметь доступ к этому файлу в первую очередь, иначе безопасность всей системы будет нарушена: просто создайте пропатченный образ ядра, который дает вам root-доступ при вызове wait4() и перезагрузке.

Может ли этот ваш специальный пользователь предоставить себе постоянный доступ к некоторым системным файлам конфигурации в /etc? Удаление нескольких из них может легко нарушить процесс загрузки, а также повредить работающую систему.

Трудно дать более точный ответ без подробностей. Например, когда вы говорите "SSH перестал работать", вы имеете в виду, что активный сеанс был принудительно закрыт, или пользователь вышел из системы и попытался снова войти? И когда вы говорите "Машина не вернется", что именно происходит? Есть какие-нибудь сообщения на консоли или вообще ничего?

В конечном счете, вам нужно проверить файловую систему, чтобы увидеть, какие файлы отсутствуют. Не может быть официального источника, в котором говорится, как именно конкретный пользователь выстрелил себе в ногу.