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

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

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

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

Прежде всего, мелкая терминология: chmodне удаляет разрешения. Это меняет их.

Теперь суть проблемы - режим 777означает «Любой может читать, писать или выполнять этот файл». - Вы дали разрешение любому делать (эффективно) все, что ему нужно.

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

1. Вы просто позволили всем читать / изменять каждый файл в вашей системе.
   • Прощайте с паролем безопасности (любой может прочитать теневой файл и взломать ваши пароли, но зачем беспокоиться? Просто ИЗМЕНИТЕ пароль! Это намного проще!).
   • Прощайте безопасность ваших двоичных файлов (кто-то может просто написать новую loginпрограмму, которая позволяет им каждый раз).
   • Поцелуй свои файлы на прощание: один пользователь неверно перенаправляет, rm -r /и все кончено. ОС было сказано, чтобы позволить им делать все, что они хотят!
2. Вы разозлили каждую программу, которая проверяет права доступа к файлам перед запуском.
   sudo, sendmailИ множество других просто не пустят больше. Они изучат права доступа к ключевому файлу, увидят, что они не те, кем они должны быть, и отправят сообщение об ошибке.
   Точно так sshже сломается ужасно (ключевые файлы должны иметь определенные разрешения, в противном случае они «небезопасны» и по умолчанию SSH откажется их использовать.)
3. Вы уничтожили биты setuid / setgid в программах, в которых они были.
   Режим 777на самом деле . Среди вещей в этой ведущей цифре есть и биты. У большинства программ, которые имеют setuid / setgid, этот бит установлен, потому что они должны работать с определенными привилегиями Они сломаны сейчас.0777setuidsetgid
   
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 /она загрузится, и вы сможете запускать процессы, у которых нет явной проверки разрешений. Таким образом, система на самом деле не мертва, просто несколько непригодна для разработки .