chmod -R робить файли в дочірніх папках чомусь зручними


22

Я коригував дозволи при налаштуванні деяких тем WordPress і запускав. chmod 664 -R theme-dir/*Це добре працювало на файлах у корені каталогу, але всі файли в підкаталогах зараз читаються так, коли я ls -l:

?---------  ? ? ? ?            ? core_functions.php
?---------  ? ? ? ?            ? css
?---------  ? ? ? ?            ? custom_functions.php
?---------  ? ? ? ?            ? images
?---------  ? ? ? ?            ? import_settings.php
?---------  ? ? ? ?            ? js
?---------  ? ? ? ?            ? options_trim.php
?---------  ? ? ? ?            ? page_templates
?---------  ? ? ? ?            ? post_thumbnails_trim.php
?---------+ ? ? ? ?            ? shortcodes

Я не можу CD в жодному з підкаталогів, а також не можу видалити їх. Я ніколи не бачив нічого подібного, хтось коли-небудь натрапляв на щось подібне?


виглядає як пошкоджена файлова система ..
alexus

1
пробігchmod -R u+rwX,go+rX,go-w theme-dir/*
Душан Баич

@ dusan.bajic Це спрацювало, дякую. Досі не маю ідеї, чому це сталося в першу чергу, хоча.
Сал

5
@alexus немає корупції, просто пермі
пташенята

Я думаю, що щось подібне я бачив, коли робив chown 644 (чи що завгодно) проти chmod, але мені справді не подобається тестувати знову на робочій системі
Foon

Відповіді:


49

Доступ до вмісту (або конкретніше метаданих файлів, крім імені файлу) каталогу, вимагає, щоб у каталозі встановлено біт виконання.

Ваш рекурсивний chmod видалив цей дозвіл, тому ви втратили цей доступ. Якщо ви використовуєте -Rпараметр chmod, краще уникати використання числової версії дозволів, а замість цього запустити (використовуючи бажаний стан як приклад) chmod -R ug=rwX,o=rX. З великої літери X там встановлено біт X лише для каталогів або файлів, що мають принаймні один xнабір. Також ви можете використовувати 644 ( u=rwX,go=rX), якщо вам справді не потрібні користувачі групи для написання.


6
X означає встановити X для каталогів та файлів, які вже мають дозвіл на виконання для певного користувача (що зазвичай те, що ви хочете)
tomclegg

1
@tomclegg: Правильно. Я відповідним чином оновив свою відповідь. Не дивно, що вони ніколи не додавали справжню версію конкретної каталогів, а ще краще лист перед операцією (наприклад, u, g, o чи a), що означає застосувати цю зміну лише до каталогів.
Кевін Кеткарт

13

З документації Wordpress :

Якщо у вас є доступ до оболонки на ваш сервер, ви можете змінювати дозволи файлів рекурсивно, використовуючи наступні команди:

Для каталогів:

find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

Для файлів:

find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Надмір для цієї конкретної проблеми, але дуже корисний в інших випадках :)
nurchi

1
Я помітив у більш чутливих до безпеки середовищах (нещодавно Magento та системи охорони здоров’я), що постачальники та системи з відкритим кодом переходять до рекомендації ТОЛЬКО за допомогою файлового методу, оскільки він дає вам повний контроль над вищезазначеними умовами, а також дозволяє тонкозернистий контроль над застосування setuid, setgid, а також сумнозвісний "клейкий біт". Мабуть, буде більше роботи, щоб вирішити це питання для цього випадку використання, але відповідь на ставку - це завжди найбезпечніший метод, який дозволяє досягти бажаного результату. Я вважаю, що безпека завжди повинна бути функцією №1, якщо це можливо собі дозволити.
Bryan 'BJ' Hoffpauir Jr.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.