Почему "chmod -R 777 /" разрушителен?

Это канонический вопрос о правах доступа к файлам и почему 777 является "разрушительным".

Я не спрашиваю, как решить эту проблему, поскольку существует множество ссылок на это уже при сбое сервера (переустановите ОС). Почему это делает что-нибудь разрушительное вообще?

Если вы когда-либо запускали эту команду, вы сразу же уничтожаете свою операционную систему. Мне непонятно, почему снятие ограничений влияет на существующие процессы. Например, если у меня нет доступа для чтения к чему-либо, и после быстрого опечатки в терминале внезапно у меня теперь есть доступ... почему это приводит к поломке Linux?

Источник

2 ответа

Решение

First of all a minor terminology nitpick: chmod doesn't remove permissions. It CHANGES them.

Now the meat of the issue -- The mode 777 означает "Любой может читать, писать или исполнять этот файл" - Вы дали разрешение на то, чтобы кто-либо делал (эффективно) все, что ему нужно.

Теперь, почему это плохо?

  1. Вы просто позволили всем читать / изменять каждый файл в вашей системе.
    • Прощайте с паролем безопасности (любой может прочесть теневой файл и взломать ваши пароли, но зачем беспокоиться? Просто ИЗМЕНИТЕ пароль! Это намного проще!).
    • Поцелуй на прощание безопасность своих двоичных файлов (кто-то может просто написать новый login программа, которая позволяет им в любое время).
    • Поцелуй свои файлы до свидания: один пользователь вводит в заблуждение rm -r / и все кончено. ОС приказали им делать все, что они хотят!
  2. Вы разозлили каждую программу, которая проверяет права доступа к файлам перед запуском.
    sudo, sendmail и множество других просто не запустится. Они изучат права доступа к ключевому файлу, увидят, что они не те, кем они должны быть, и отправят сообщение об ошибке.
    так же ssh сломается ужасно (ключевые файлы должны иметь определенные разрешения, в противном случае они "небезопасны" и по умолчанию SSH откажется их использовать.)
  3. Вы уничтожили биты setuid / setgid в программах, в которых они были.
    Режим 777 на самом деле 0777, Среди вещей в этой ведущей цифре есть setuid а также setgid биты.
    У большинства программ, которые имеют setuid / setgid, этот бит установлен, потому что они должны запускаться с определенными привилегиями. Они сломаны сейчас.
  4. Ты сломал /tmp а также /var/tmp Другая вещь в той восьмеричной цифре, которая получила ноль, это sticky bit - То, что защищает файлы в /tmp (а также /var/tmp) от удаления людьми, которым они не принадлежат.
    Существует (к сожалению) множество скриптов с плохим поведением, которые "очищают", выполняя rm -r /tmp/* и без липкого бита, установленного на /tmp Вы можете поцеловать все файлы в этом каталоге до свидания.
    Исчезновение скретч-файлов может сильно расстроить некоторые плохо написанные программы...
  5. Вы вызвали хаос в /dev/proc и подобные файловые системы
    Это больше проблема на старых системах Unix, где /dev настоящая файловая система, и в ней содержатся специальные файлы, созданные с mknodТак как изменение разрешений будет сохраняться при перезагрузке, но в любой системе, в которой изменение разрешений вашего устройства может привести к существенным проблемам, от очевидных угроз безопасности (каждый может прочитать каждый TTY) до менее очевидных потенциальных причин паники ядра.
    Credit to @Tonny for pointing out this possibility
  6. Сокеты и каналы могут сломаться или иметь другие проблемы. Сокеты и каналы могут полностью сломаться или подвергнуться злонамеренному внедрению в результате того, что они становятся доступными для записи всем пользователям.
    Credit to @Tonny for pointing out this possibility
  7. Вы сделали каждый файл в вашей системе исполняемым
    У многих людей есть . в их PATH переменная окружения (вы не должны!) - это может вызвать неприятный сюрприз, так как теперь любой может удалить файл с удобным именем, например, командой (скажем, make или же ls и попытаться заставить вас запустить их вредоносный код.
    Credit to @RichHomolka for pointing out this possibility
  8. На некоторых системах chmod сбросит списки контроля доступа (ACL)
    Это означает, что вам может понадобиться пересоздать все ваши ACL в дополнение к повсеместному фиксированию разрешений (и это реальный пример разрушительной команды).
    Credit to @JamesYoungman for pointing out this possibility

Будут ли работать уже запущенные части системы? Возможно, хотя бы на время.
Но в следующий раз, когда вам нужно будет запустить программу, или перезапустить службу, или, боже, запретите перезагружать коробку, в которой вы живете, мир, в котором вы страдаете, так как № 2 и № 3 выше поднимут свои уродливые головы.

Источник

Одна важная вещь состоит в том, что есть много инструментов, таких как ssh / sudo, которые проверяют разрешения файловой системы для ключевых файлов конфигурации. Если разрешения неправильные, эти инструменты предназначены для сбоя, поскольку это указывает на серьезную проблему безопасности. В моей тестовой системе Debian и, возможно, в других, возможность входа в систему не выполняется, возможно, из-за того, что двоичный файл входа в систему или что-то в PAM имеет проверку прав доступа.

Так что на самом деле система не разрушена, а в том, что многие инструменты предназначены для немедленного сбоя при неправильных разрешениях.

Если вы перезагрузите систему после выполнения chmod 777 -R / он загрузится, и вы сможете запускать процессы, которые не имеют явной проверки разрешений. Таким образом, система на самом деле не мертва, просто несколько непригодна для разработки.

Источник
Другие вопросы по тегам