Почему запуск "$ sudo chmod -R 664." Приводит к тому, что мне запрещен доступ ко всем затронутым каталогам?

Question

У меня есть папка проекта, которая имеет грязные разрешения на все файлы. У меня была плохая тенденция устанавливать все в восьмеричные разрешения 777, потому что это решало все проблемы, не связанные с безопасностью. Затем загрузка по FTP, файлы, созданные текстовыми редакторами и т.д., Имеют собственный набор разрешений, что делает все беспорядочным. Я решил взять себя в руки и начать использовать разрешения так, как они должны были использоваться.

Я полагал, что 664 был хорошим значением по умолчанию для всех моих файлов и папок, и я просто удалил разрешения для других в личных файлах и добавил +x для исполняемых файлов.

Второй я изменил папку проекта на 664 однако:

$ sudo chmod -R 664 .  
$ ls  
ls: cannot open directory .: Permission denied  

Что не имеет смысла для меня. У меня есть разрешения на чтение / запись, и я являюсь владельцем папки проекта. Самая левая часть ls -l в папке моего проекта выглядит так:

-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 5 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 3 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 4 codemonkey codemonkey ...
drw-rw-r-- 5 codemonkey codemonkey ...

Я предполагаю, что это как-то связано с разрешениями на каталоги, но что?

Answer 1

Вам необходимо выполнить разрешения для каталогов.

Рассматривать

sudo find -type d -exec chmod +x {} +

---

Обновление: вот мое объяснение этого, по-видимому, странного использования разрешений на выполнение.

Unix (и, следовательно, Linux) в значительной степени рассматривает все как файлы. Это распространяется на диски и различные другие устройства. это также включает каталоги.

Традиционные файловые системы Unix имеют набор разрешений, которые применяются к файлам. Поэтому разработчикам Unix приходилось находить что-то полезное для каждого бита разрешений, которое нужно применять применительно к "файлу", который не был вашим обычным файлом данных.

Давайте рассмотрим каталоги. Первоначально кажется разумным просто использовать разрешение на чтение, чтобы решить, может ли кто-то получить доступ к каталогу - например, для создания списка файлов в нем, их размеров и меток даты и т.д.

Однако предположим, что вы хотите, чтобы обычные пользователи могли запускать программы в /usr /local /bin, но вы не хотите, чтобы они могли копаться в /usr /local, чтобы посмотреть, что там. Если у вас есть только разрешение на чтение, вы не можете предотвратить это.

Таким образом, избыточное разрешение на выполнение было использовано для контроля того, разрешено ли вашей оболочке "проходить" каталог, что означает, что мы больше не выясняем, что необходимо для того, чтобы иметь возможность находить и читать подробности подкаталога как пути. Это позволяет вам попасть в каталог /usr /local только настолько, насколько это необходимо для чтения содержимого /usr /local /bin.

Таким образом, +x для /usr /local означает, что вы можете запустить "/usr /local /bin /foo". Но +r для /usr /local означает, что вы можете найти все, что находится в /usr /local, включая информацию о том, кому он принадлежит, какие разрешения каждый файл имеет, какой он был и т. д.

Вышесказанное основано на смутных воспоминаниях и догадках. Это может быть не совсем верно, но я считаю, что это дает разумное представление о том, почему "выполнить" означает "способный пройти".

Answer 2

Бит выполнения необходим для прохождения каталога * nix. Вы не можете cd в каталог, для которого у вас нет прав на выполнение, и это влияет на ряд утилит неочевидными способами, если им нужен контекст каталога. Рассматривать:

$ cd /tmp
$ mkdir foo
$ echo baz > foo/bar
$ chmod a-x foo

# You can read the contents of the directory, but ls still complains. 
$ ls foo
ls: cannot access foo/bar: Permission denied
bar

# You can't read the file because you can't enter the directory.
$ cat foo/bar
cat: foo/bar: Permission denied

Причиной всего этого является то, как работает stat(). Выдержка из man 2 stat:

Для самого файла не требуются разрешения, но - в случае stat() и lstat() - разрешение на выполнение (поиск) требуется для всех каталогов в пути, которые ведут к файлу.

Суть в том, что рекурсивный chmod редко будет делать то, что вы ожидаете, и будет разрушать права доступа на чтение и выполнение каталога, что может привести к неожиданным результатам, подобным вашим. Всегда рассматривайте права доступа к каталогу отдельно от прав доступа к файлу для достижения наилучших результатов.