Чому "chmod -R 777 /" руйнує?

Це канонічне запитання про дозвіл файлів і чому 777 є "руйнівним".

Я не запитую, як виправити цю проблему, оскільки є безліч посилань на це вже на серверній помилці (перевстановлення ОС). Чому це взагалі робить щось руйнівне?

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

Перш за все, незначна термінологія nitpick: chmodне видаляє дозволи. Це ЗМІНУЄ їх.

Тепер суть випуску - Режим 777означає "Будь-хто може читати, писати чи виконувати цей файл" - Ви дали дозвіл для того, щоб хто-небудь міг (ефективно) робити все, що б він не хотів.

Тепер, чому це погано?

1. Ви просто дозволили всім читати / змінювати кожен файл у вашій системі.
   • Поцілунок безпеки безпеки до побачення (кожен може прочитати тіньовий файл і зламати ваші паролі, але навіщо це турбувати? Просто ЗМІНІТЬ пароль! Це набагато простіше!).
   • Поцілуйте безпеку для ваших бінарних файлів (хтось може просто написати нову loginпрограму, яка дозволяє щоразу).
   • Поцілуйте свої файли до побачення: один користувач неправильно спрямовує, rm -r /і все закінчилося. ОС сказали, щоб вони дозволяли робити все, що завгодно!
2. Ви озлобили кожну програму, яка перевіряє дозволи на файли перед запуском.
   sudo, sendmailі безліч інших просто більше не почнеться. Вони вивчать основні дозволи файлів, побачать, що вони не є такими, якими вони повинні бути, і відкинуть повідомлення про помилку.
   Аналогічно sshзламається жахливо (ключові файли повинні мати конкретні дозволи, інакше вони "небезпечні", і SSH за замовчуванням відмовиться їх використовувати.)
3. Ви видалили встановлені / 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 /вона завантажиться, і ви можете запустити процеси, які не мають явних перевірок дозволу. Таким чином, система насправді не мертва, просто дещо непридатна для дизайну .