Чому chmod 777 -R / залишає систему непридатною?


52

Я даю лише дозвіл усім робити що-небудь, але чому система виходить з ладу, даючи лише дозволи? Я лише змінюю дозвіл, не змінюючи файли.



2
Я думаю, це не збій, а просто переривання процесу завантаження в якийсь момент. Якби ви подивилися /var/log/syslog, ви навіть зрозуміли причину.
Привіт-Ангел

7
Важливо знати, що навіть якби це не порушило речі, це не "надасть дозвіл усім робити що-небудь". Існує ще велика кількість дій, які можна було б виконати лише «root» (точніше, процес з ефективним нулем UID).
zwol

6
@Glen, якщо під "спорідненим" ви маєте на увазі "точний дублікат, який показує, чому ми повинні мати можливість позначити як дуп на всіх сайтах", тоді обов'язково! чудове посилання. ;)
підкреслюй_d

4
Мені б дуже хотілося почути історію про вас, задавши це питання.
Деві Морган

Відповіді:


104

Причин є кілька.

По-перше, крім звичайних дозволів на читання / запис / виконання / є деякі інші біти, які містять дозволи файлів. Найбільше setuidі setgid. Коли програма з одним із цих бітів дозволу запускається, вона отримує "ефективний UID" та / або "ефективний GID" власника програми, а не користувача, який її запускав. Це дозволяє програмам запускатися з більшою кількістю дозволів, ніж користувач, який ними керував. Він використовується багатьма ключовими утилітами, включаючи suта sudo. Ваша chmodкоманда очищає ці біти, залишаючи утиліти непридатними.

По-друге, деякі програми (зокрема ssh) перевіряють дозволу на файли та відмовляються використовувати файли з дозволами, які вони вважають небезпечними. Це знижує ризик необережних адміністраторів випадково залишити отвори у безпеці, але це робить ще більш болючим справу зі знищеними дозволами на файли.


41

Коротка відповідь.

Система Linux вимагає конкретних дозволів для певних програм, наприклад sudoтощо.

Під час запуску chmod 777 -R /ви стираєте всі дозволи та заміняєте їх 777. Це робить систему непридатною, якщо ви вручну не відновите всі дозволи.

На практиці це набагато швидше і простіше перевстановити.

Проблема полягає в тому, що багато системних програм розроблені таким чином, що вони не запускаються, якщо вони "не люблять" дозволи. Це зроблено з міркувань безпеки.

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

Якщо ви дійсно хочете, щоб усі користувачі мали необмежені дозволи в Ubuntu, ви можете додати всіх користувачів до sudoгрупи замість зміни дозволів на файли та каталоги. Це матиме такий же ефект, але не зіпсує систему.

Інший спосіб (дуже поганий) - активувати кореневий рахунок і дозволити всім входити як root.


11
Можливо, хтось знайде час і детально відповість ;-)
Pilot6

1
Я міг би вказати на кращий спосіб дозволити всім робити все в цій системі - але писати поглиблену статтю про те, чому кожному бінарному потрібні конкретні дозволи, налаштування та прапори - це занадто багато, імхо. ;-)
Phillip -Zyan K Lee- Stockmann

4
Системи Linux не розроблені так, щоб усі могли робити все. Ви можете ввімкнути кореневий обліковий запис, і кожен може ввійти як root для цього. Це дурно, але це шлях.
Пілот6

9
Отже, Pilot6, ви хочете сказати, що системні програми були розроблені таким чином, що якщо дозвіл піде не так, вони не можуть / можуть працювати належним чином? І будь ласка Pilot6, якщо можливо, надайте більш глибоку відповідь із прикладами та поясненнями, чому певні програми потребують обмежених дозволів. Дякую.
Brij Raj Kishore

13
@Goldname Збій - це помилка - це ціла кількість програм, які говорять: «Я не можу виконувати критичні функції з системою в такому стані, тому я перериваю»
Шадур,

32

chmod має тонкі нюанси.

chmod 0777поводиться інакше, ніж chmod u+rwx,g+rwx,o+rwxу тому, що setuid та setgid нулюються першими та зберігаються останніми.

Ось чому система стала непридатною. Ви видалили необхідні налаштування з кількох програм.

Ось список встановлених або встановлених файлів на моєму ноутбуці Linux Fedora 23:

[root@fedora23lnvr61]# find / -perm /g+s,u+s
/var/log/journal
/var/log/journal/75e870eb13c74fbf97556a32ecf80ea2
/opt/google/chrome/chrome-sandbox
/usr/bin/rogue
/usr/bin/gnuchess
/usr/bin/locate
/usr/bin/umount
/usr/bin/lbrickbuster2
/usr/bin/gpasswd
/usr/bin/crontab
/usr/bin/fusermount
/usr/bin/su
/usr/bin/at
/usr/bin/newuidmap
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/mount
/usr/bin/chsh
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/chage
/usr/bin/chfn
/usr/bin/write
/usr/bin/newgidmap
/usr/sbin/mount.nfs
/usr/sbin/lockdev
/usr/sbin/netreport
/usr/sbin/userhelper
/usr/sbin/usernetctl
/usr/sbin/unix_chkpwd
/usr/sbin/pam_timestamp_check
/usr/libexec/kde4/kdesud
/usr/libexec/kde4/kpac_dhcp_helper
/usr/libexec/dbus-1/dbus-daemon-launch-helper
/usr/libexec/qemu-bridge-helper
/usr/libexec/openssh/ssh-keysign
/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper
/usr/libexec/utempter/utempter
/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache
/usr/libexec/Xorg.wrap
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/lib64/vte-2.90/gnome-pty-helper
/usr/lib64/virtualbox/VBoxSDL
/usr/lib64/virtualbox/VirtualBox
/usr/lib64/virtualbox/VBoxNetNAT
/usr/lib64/virtualbox/VBoxHeadless
/usr/lib64/virtualbox/VBoxNetDHCP
/usr/lib64/virtualbox/VBoxNetAdpCtl
/usr/lib64/virtualbox/VBoxVolInfo
/usr/lib64/vte/gnome-pty-helper
[root@fedora23lnvr61]# 

Я видалив десятки записів шуму в кешах і журналах.


3
Смію, мені цікаво, чому в цьому списку є гнучки та шахраї?
WiseOldDuck

2
@WiseOldDuck: Я очікую, що в іграх є небагато, щоб вони могли оновити файл "високого бала", але не дозволяти жодному непривілейованому користувачеві робити це.
wallyk

3
@WiseOldDuck Як каже wallyk, плюс, пам’ятайте, що setuid не має несесеріально використовувати root (а afaik setgid не дуже корисний для root)
StarWeaver

5
Був би задумавшись пояснити, що chmodробиться, та навести приклади доказів, чого деінде дуже бракує.
підкреслюй_d

1
Чи означає це, що chmod u+rwx,g+rwx,o+rwx -R /не порушить систему?
Денніс Джахеруддін

15

На додаток до інших відповідей: ви також видалили "клейкий біт" /tmp(який зазвичай має дозволи 1777), і це може спричинити інші несподівані проблеми, оскільки програми зможуть записувати або видаляти тимчасові файли один одного.

Клейкий біт - це спеціальний дозвіл, який, хоча дозволяє кожному створювати файли /tmp, дозволяє особі, яка його створила, лише переміщати чи видаляти.


4
"і це не дозволило б будь-кому, окрім root, використовувати каталог system / tmp." - Це не здається правильним. Це все ще дозволить кожному користуватися каталогом system / tmp. Жоден клейкий біт не потрібен, якщо користувач, група та інші мають усі права. Однак це дозволить кожному видалити файли інших осіб.
hvd

1
так Бен Якщо я запускаю chmod 1777 -R /, то не повинно виникнути проблем, оскільки я не очищаю клейкий біт? -
Brij Raj Kishore

Дякую @hvd - ти маєш рацію, і я трохи змінив пост, щоб це відобразити.
Бен XO

@BrijRajKishore, залишається питання, чому ти робиш це в першу чергу. Ubuntu та програми, що входять до його складу, не розроблені для запуску "без дозволу" з багатьох причин. Більш розумним було би "su" викорінювати замість цього.
Бен XO

1
Невідомо, чи це призведе до аварії. Цілком можливо, що це станеться, оскільки раптом програми зможуть робити речі один одному тимчасовими файлами - можливо, випадково - і це може спричинити збій. Оскільки Ubuntu ніколи не випробовується так, ви, ймовірно, будете першою людиною, яка це дізналася. :-) З іншого боку, встановлення клейкого біта на кожну папку в системі може спричинити багато інших проблем, з програмами, які очікували, що зможуть управляти програмами через групові дозволи на папку (тобто папки з дозволами 2777).
Бен XO
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.