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

461
monkeymatrix

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

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 в то время, поэтому мне интересно, как он мог выполнить эту команду, чтобы сделать что-то подобное вообще.

2
Был ли у этого пользователя права root? Пользователь без полномочий root не должен быть в состоянии вызвать разрушительные изменения. Если вам нужны данные с компьютера, а это экземпляр с поддержкой EBS, вы можете подключить устройство хранения к другой виртуальной машине и восстановить его таким образом. qasdfdsaq 8 лет назад 0
Спасибо, и это действительно то, чем я и занялся. У пользователя не было рута, поэтому я удивлен, что он мог двигаться так же, как и он. Глядя на подключенный диск / home / теперь полный беспорядок системных папок. monkeymatrix 8 лет назад 0
+1 за выражение * мой особенный пользователь *. Вы действительно прощающий тип. MariusMatutiae 8 лет назад 1
Без корневого доступа (или доступа к root через sudo) пользователь не смог бы перемещать какие-либо файлы под `/`. Вы на 100% уверены, что у них не было такого доступа? Это, конечно, предполагает, что у вас не было никаких системных файлов с нечетными правами доступа (например, права на запись для пользователей без полномочий root) ... mjturner 8 лет назад 0

2 ответа на вопрос

2
ukesh upendran

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

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

Вы правы, но это требует лучшего объяснения. MBR или EFS не будут перемещены введенной командой, и ядро ​​не было перемещено, поэтому я подозреваю, что / etc / grub был перемещен, поэтому загрузчик GRUB 2-го этапа не работает, так как не может найти требуемый конфигурационные файлы. Вы можете попробовать загрузить машину по сети или использовать livevd, чтобы попытаться восстановить grub с помощью boot-repair. Я подозреваю, что вы уже попробовали это, и это не сработало. Обратите внимание, что / etc / также содержит данные nvram, поэтому это чрезвычайно важно. Проверьте это один раз. Tamoghna Chowdhury 8 лет назад 0
Спасибо за это объяснение, @TamoghnaChowdhury. Я не имел в виду, что MBR или EFS будут перемещены. Ядро будет находиться в загрузочном устройстве, в данном случае на диске, для загрузки загрузчика в память. Таким образом, если загрузчик grub, grub.cfg будет содержать информацию о списке загружаемых ядер и расположении каждого ядра. По умолчанию расположение ядра будет в / boot, чтобы загрузчик мог загрузить это сжатое ядро ​​в память и распаковать его (опять же, все это зависит от архива). ukesh upendran 8 лет назад 0
Может ли это быть достигнуто с пользователем, который не имеет root? monkeymatrix 8 лет назад 2
@monkeymatrix В принципе, нет, не должно. Попробуйте сами: попробуйте вывести как обычный пользователь любую команду, скажем, из / bin ,, и вам будет отказано в разрешении Permisison. Это относится как к загрузочным файлам, так и к обычным командам. MariusMatutiae 8 лет назад 0
0
Dmitry Grigoryev

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

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

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

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

Похожие вопросы