Неправильно встановлено chmod / 777. Проблеми?

Я намагався запустити, chmod -R 777 ./але закінчив набирати текст chmod -R 777 /і налаштовував 777на всю свою машину. Що може піти не так? Як я можу це виправити?

Проблеми? Так, партії. Чи можна це виправити? Звичайно. Швидше, ніж перевстановлення? Напевно, ні.

Моя рекомендація - перевстановити. Зберігайте резервну копію існуючої системи та відновлюйте список пакунків та вміст файлів у /etcта /var. Тому що /usr/localви, ймовірно, можете відновити дозволи вручну. Для /homeі /srvвам доведеться відновити дозволи з резервного копіювання.

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

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

Якщо ви дійсно хочете спробувати відновити (скоріше навчальну вправу, ніж практичний шлях відновлення), спочатку відновіть дозволи кількох файлів. Зверніть увагу , що в той час як більшість файлів тепер знаходяться занадто відкриті, деякі з них відсутні необхідні УІПИ біт. Ось такі кроки, які ви повинні зробити перед усім. Зауважте, що це не вичерпний список, а лише спроба зробити систему ледь функціональною.

chmod -R go-w /
chmod 440 /etc/sudoers
chmod 640 /etc/shadow /etc/gshadow
chmod 600 /etc/ssh/*_key /etc/ssh*key   # whichever matches
chmod 710 /etc/ssl/private /etc/cups/ssl
chmod 1777 /tmp /var/tmp /var/lock
chmod 4755 /bin/su /usr/bin/passwd /usr/bin/sudo /usr/bin/sudoedit
chmod 2755 /var/mail /var/spool/mail

Тоді вам потрібно буде відновити всі дозволи всюди. Для файлів під /usr, ви можете перевстановити пакети за допомогою однієї з наступних команд, залежно від вашого розповсюдження:

• Якщо ви використовуєте Debian, Ubuntu або інший дистрибутив на основі APT, ви можете виконати apt-get --reinstall install
• Якщо ви використовуєте Arch Linux, ви можете виконати pacman -S $(pacman -Qq --dbpath /newarch/var/lib/pacman) --root /newarch --dbpath /newarch/var/lib/pacman, припускаючи, що ви знаходитесь на компакт-диску Live, і ваша установка Arch встановлена ​​на /newarch.

Для файлів під /etcі /var, це не працюватиме, оскільки багато з них залишиться як і раніше: вам доведеться повторити дозволи на робочу інсталяцію. Для файлів під /srvі /home, будь-коли, вам доведеться відновити їх із резервних копій. Як бачите, ви також можете перевстановити.

Ви можете спочатку цього не помітити, але багато речей можуть і піти не так. Основна проблема полягає в тому, що вся модель безпеки для всієї системи порушена. Це як би мати тіло без шкіри, органи все на повітрі. Це повинно заразитися, оскільки воно не призначене для того, щоб функціонувати так. Навіть якщо це, здається, працює кілька хвилин, вам потрібно це почистити.

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

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

РІШЕННЯ: Я випробував це в ЦЕНТРАХ

Цей хлопець врятував мою роботу! (Вам потрібно якось отримати доступ)

http://www.adminlinux.org/2009/07/how-to-restore-default-system.html

1) Щоб скинути uids та gids на файли та каталоги:

for u in $(rpm -qa); do rpm --setugids $u; done

2) Дозволів на файли та каталоги

for p in $(rpm -qa); do rpm --setperms $p; done

потім змініть дозволи вручну на ці файли:

# ll /etc/ssh/
# chmod 600 /etc/ssh/ssh_host_rsa_key
# chmod 600 /etc/ssh/ssh_host_dsa_key
# service sshd restart

Деякі програми, що захищають безпеку, не запускатимуться, якщо певні файли мають надто "втрачений" дозвіл. Як сказав @ceving, sshdнайбільш типовим для цього є.

Головне, що може піти не так - тепер будь-який користувач може відкривати, читати та писати будь-який файл у вашій системі. Дві причини, чому це погано, це: А) якщо зловмисний користувач отримує контроль над вашою системою через експлуатацію або неправильну конфігурацію, він / вона може змінити будь-що у вашій системі зараз, і B) ви можете видалити все, що завгодно, навіть якщо ви не root, тому ви просто заперечували більшість захистів, що не виконуються як root.

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