Как разрешения для файлов применяются к символическим ссылкам?

Допустим, у вас есть эта структура:

+ 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 может использоваться для изменения разрешений символической ссылки, используя такие параметры, как этот (from 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, не указано.

Здесь «неопределенное» оставляет место интерпретации для каждой реализации. Особенности:

• В Linux (протестировано с использованием ext4fs) stat()возвращает значение st_mode=0777независимо от того, каким был umask при создании символической ссылки; ls -lпоэтому всегда отображается lrwxrwxrwxдля символических ссылок.
• В macOS (HFS) и FreeBSD (как UFS, так и ZFS) символическая ссылка имеет свое собственное разрешение: chmod -hуказанная выше команда может изменить разрешение этой ссылки (которая для этого использует lchown()системный вызов не-POSIX ), а также stat()систему call возвращает это значение для st_mode.

Символические ссылки в Linux и FreeBSD всегда могут быть использованы, как указано в POSIX. В частности, во FreeBSD это означает, что файловый режим символьной ссылки вообще не влияет на управление доступом.

С другой стороны, macOS слегка ломает POSIX. Хотя по символической ссылке можно следовать независимо от разрешения на чтение, происходит readlink()сбой с EACCES(Отказано в доступе), если у пользователя нет разрешения на чтение:

$ 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()ссылки для контроля и обхода ссылки.

1. удалить файл ссылки (убедившись, что он не используется каким-либо процессом)
2. установите umask таким образом, чтобы 777-umask = требуемые права доступа к файлу
3. создать файл ссылки заново