Допустим, у вас есть эта структура:
+ directory
-- file1
-- file2
-- file3 -> /tmp/file3
file3 - это ссылка на другой file3 где-то еще в системе.
Теперь допустим, что я chmod 777 каталог и все содержимое в нем. Мой file3 в /tmp получает эти разрешения? Также, скажем, у нас такая же ситуация, но обратная.
/tmp/file3 -> /directory/file3
Если я применяю разрешения к файлу, на который идет ссылка, как это повлияет на ссылку?
Это зависит от того, как вы вызываете chmod и от платформы, на которой вы работаете.
Например, в системе Linux man chmod говорит следующее:
chmodникогда не меняет права доступа к символическим ссылкам; системный вызовchmodне может изменить их разрешения. Это не проблема, поскольку разрешения символических ссылок никогда не используются. Однако для каждой символической ссылки, указанной в командной строке,chmodизменяет права доступа к указанному файлу. Напротив,chmodигнорирует символические ссылки, встречающиеся во время рекурсивных обходов каталогов.
Однако на Mac chmod может использоваться для изменения разрешений символической ссылки, используя такие параметры, как этот (от man chmod):
-h Если файл является символической ссылкой, измените режим самой ссылки, а не файла, на который указывает ссылка.
Для примера, давайте предположим, что вы находитесь на машине с Linux до конца этого ответа.
Если в первом случае вы запустите chmod -R 777 directory для рекурсивного изменения разрешений, цель ссылки не будет затронута, но если вы выполните chmod 777 directory/* , то это произойдет.
Если вы измените разрешения для цели ссылки напрямую, эти разрешения будут выполняться (поскольку, как говорят man-страница и baraboom , фактические разрешения ссылки ни для чего не используются).
Журнал испытаний для иллюстрации:
$ mkdir dir && touch dir/file{1,2} /tmp/file3 && ln -s {/tmp,dir}/file3
$ ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group 0 2011-06-27 22:02 /tmp/file3
-rw-r--r-- 1 user group 0 2011-06-27 22:02 dir/file1
-rw-r--r-- 1 user group 0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3
$ chmod -R 777 dir && ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group 0 2011-06-27 22:02 /tmp/file3
-rwxrwxrwx 1 user group 0 2011-06-27 22:02 dir/file1
-rwxrwxrwx 1 user group 0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3
$ chmod 700 dir/* && ls -l dir/* /tmp/file3
-rwx------ 1 user group 0 2011-06-27 22:02 /tmp/file3
-rwx------ 1 user group 0 2011-06-27 22:02 dir/file1
-rwx------ 1 user group 0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3
ответы baraboom в и Peth являются как правильно: биты разрешений на символические ссылки сами не имеют отношения ( за исключением MacOS, смотрите ниже), и изменение разрешения на символической ссылки - с помощью chmod инструмент командной строки или с помощью chmod() системного вызова ()- будет просто действовать, как если бы он был выполнен против цели символической ссылки.
Чтобы процитировать SUSv4/POSIX.1-2008 описание системного вызова symlink():
Значения битов режима файла для созданной символической ссылки не определены. Все интерфейсы, указанные в POSIX.1-2008, должны вести себя так, как будто содержимое символических ссылок всегда можно прочитать, за исключением того, что значение битов режима файла, возвращаемых в поле st_mode структуры stat, не указано.
Здесь «неопределенное» оставляет место интерпретации для каждой реализации. Особенности:
stat() возвращает st_mode=0777 , независимо от того, каким был umask при создании символической ссылки; Поэтому ls -l всегда отображает lrwxrwxrwx для символических ссылок.chmod -h может изменить это разрешение ссылки (которое внутренне использует системный вызов не-POSIX lchown() для достижения this), и системный вызов stat() возвращает это значение для st_mode .Символические ссылки в Linux и FreeBSD всегда могут быть использованы, как указано в POSIX. В частности, во FreeBSD это означает, что файловый режим символьной ссылки вообще не влияет на управление доступом.
С другой стороны, macOS слегка ломает POSIX. Хотя по символической ссылке можно следовать независимо от разрешения на чтение, readlink() завершается ошибкой с EACCES (Permission denied), если у пользователя нет разрешения на чтение:
$ sudo ln -shf target symlink
$ sudo chmod -h 444 symlink
$ ls -l symlink
lr--r--r-- 1 root staff 1 Mar 14 13:05 symlink -> target
$ sudo chmod -h 000 symlink
$ ls -l symlink
ls: symlink: Permission denied
l--------- 1 root staff 1 Mar 14 13:05 symlink
$ echo kthxbye > target
$ cat symlink
kthxbye
(Обратите внимание, что -> target часть -> отсутствует в выходных данных второй команды ls -l , и что cat symlink все же преуспела и напечатала содержимое target файла, даже если у пользователя не было разрешения на чтение symlink .)
NetBSD, по-видимому, предлагает специальную опцию монтирования под названием symperm которая, если она установлена, вызывает символические разрешения на чтение / выполнение ссылки для управления readlink() и обходом ссылки.