Время от времени (часто довольно долго) у меня возникают трудности, когда я выполняю команду, которая полностью портит работу машины Linux.
Совсем недавно я случайно снова смонтировал корневой раздел (думая, что это новый USB-накопитель, который я только что отформатировал), а затем приступил к рекурсивному chown-присвоению раздела себе (опять же, просто пытаясь предоставить себе пользовательский доступ к USB-накопителю). Как только я понял, что я сделал (в середине процесса), я прервал его, но ущерб был нанесен. Многие основные программы больше не были привилегированными, поэтому машина, по сути, находилась в состоянии зомбирования. Некоторые пользовательские функции (ssh, rsync) все еще работали, но административные функции были полностью заблокированы. Невозможно было монтировать, размонтировать, повторно подключаться к сеансам screen, перезагружать и т. д.
Если бы машина была здесь, в гостиной, со мной, ее "ремонт" (переустановка) был бы тривиально прост. Но это не так. Она в доме моего брата. Он не в восторге от того, что я провожу его через ремонт/переустановку, и я это понимаю. Так что я пойду через несколько дней, чтобы исправить то, что я нанес (и, надеюсь, установить что-то более устойчивое к административным ошибкам).
Я говорю все это для того, чтобы задать вопрос: какие рекомендуются способы защиты установки от неуклюжести администратора?
Вещи, которые не были учтены или были учтены и быстро отброшены:
- Заставить администратора не выполнять глупые команды: Отличная идея, но она не сработает, потому что, как человек, я иногда делаю вещи, которые, как я понимаю постфактум, являются плохой идеей. Я хочу перехитрить себя заранее, чтобы, когда я сделаю что-то глупое, машина откажется, и я пойму: «О, черт! Это могло быть Очень Плохо (TM)! Давайте больше так не делать».
Я рассмотрел следующие моменты:
- Монтировать корневой раздел только для чтения: защитит корень от изменений, которые могут иметь негативные последствия, если предполагается, что части будут доступны для записи, но не будут. Также не обязательно защитит раздел от повторного монтирования в другом месте как чтение-запись.
- Используйте какой-либо сжатый образ корневого каталога, доступный только для чтения, с записываемым слоем типа union поверх него, чтобы в корневой каталог не вносились никакие изменения, а перезагрузка устраняла все ошибки: Это было бы нормально/хорошо, если бы не требовалось вносить никаких изменений в корневой каталог, и, возможно, /etc можно было бы перезагрузить/заполнить из постоянного файла где-то в другом месте.
- Используйте Btrfs с регулярными (возможно, ежедневными) снимками, чтобы в случае возникновения ошибки восстановление было проще: Это все равно может быть неоптимальным вариантом, поскольку потребует прямого вмешательства пользователя, и я не знаю, смогу ли я провести кого-то еще через изменения, чтобы откатить их обратно.
- Используйте более «живой»/«встроенный» дистрибутив Linux/BSD, разработанный с учетом стабильности/предсказуемости/безопасности, а не более универсальный дистрибутив.
На данный момент я, скорее всего, воспользуюсь вариантом 4, чтобы установить несколько более ограниченную систему, чем полная установка Debian, которую я использовал. Но как просто файловый сервер и торрент-клиент, он должен работать нормально, а как удаленная машина, защита машины от меня самого — довольно большой актив.
решение1
Суровая правда в том, что ничто не защитит вас от вашей собственной глупости. Интерфейса DWIM (делай то, что я имею в виду) не существует. Компьютер не может отличить намеренное от случайного. Неважно, сколько абстракций вы нагромождаете, неверная случайная команда может все это разрушить.
Простой ответ —замедлитесь и обратите внимание на то, что вы делаете.
решение2
Запустите установку на виртуальной машине. Сделайте снимок известного хорошего состояния. Сделайте снимки, прежде чем делать что-то рискованное. Не делайте почти ничего в среде хоста. Если вы облажались, подключитесь к среде хоста и восстановите снимок.
решение3
Ничто не мешает вам выстрелить себе в ногу. Вы «думали», что корневой раздел — это USB-флешка. Вы могли бы с такой же легкостью принять важную машину за одноразовую виртуальную машину. (Случается с лучшими из нас)
Важно сделать так, чтобы услуги, предоставляемые вашими компьютерами, были избыточными.
В этом случае вы могли бы иметь две версии Linux, установленные на двух отдельных разделах. Вы можете сказать своему брату, чтобы он загрузился в другой. (Просто идея)
Самое главное — делать резервные копии и иметь стратегию восстановления.
В этом случае, поскольку вы взяли на себя ответственность за компьютер своего брата, вам следует постоянно делать резервные копии всех данных, которые вы можете, и иметь несколько копий у себя.
Вы также можете предоставить своему брату USB-накопитель Linux для загрузки с SSH-сервером и установленным паролем. И настроить его ПК на загрузку с USB. Затем в экстренной ситуации просто попросите его вставить USB-накопитель и перезагрузить ПК.
решение4
Не делайте ничего как пользователь root. Настройте sudo, чтобы разрешить вашей обычной учетной записи делать что-то root, но с паролем. Это даст вам последний шанс увидеть, что вы на самом деле делаете.
Но когда вы работаете как root, настройте псевдонимы для общих команд, которые заставляют интерактивное использование. например, alias rm="rm -i"сделает rmзапрос перед удалением. Вы можете явно переопределить с помощью -f(сознательное решение), если вы действительно этого хотите rm *(тогда будет rm -f *).
Вы не сказали, какая FS была на USB. Обычно это VFAT. Вы можете смонтировать их с опциями, чтобы каждый файл уже выглядел как принадлежащий определенному пользователю. Тогда вам никогда не придется запускать chown -r ...и, таким образом, исключить возможность ошибки.
Сделайте приглашение root-оболочки красным, чтобы напомнить вам, что вы работаете с повышенными привилегиями.
В целом, это затрудняет выполнение действий с правами root, создавая такие препятствия, как запросы на ввод пароля и т. д.
Теперь, после того, как вы исправите это, вы можете получить доступ к другой машине, похожей на эту, и использовать ее, findчтобы показать вам программы SUID/SGID. Затем сопоставьте поврежденный диск с этим с помощью chmodкоманды.