Como as permissões de arquivo se aplicam aos links simbólicos?

Digamos que você tenha essa estrutura:

+ directory
-- file1
-- file2
-- file3 -> /tmp/file3

file3é um link para outro file3em outro lugar do sistema.

Agora digamos que eu chmod 777o diretório e todo o conteúdo dentro dele. O meu file3em /tmpreceber essas permissões? Além disso, digamos que temos a mesma situação, mas revertida.

/tmp/file3 -> /directory/file3

Se eu aplicar as permissões no arquivo ao qual está sendo vinculado, como isso afeta o link?

Depende de como você chama chmode da plataforma em que está executando.

Por exemplo, em um sistema Linux, man chmoddiz o seguinte:

chmod nunca altera as permissões de links simbólicos; a chmod chamada do sistema não pode alterar suas permissões. Isso não é um problema, pois as permissões de links simbólicos nunca são usadas. No entanto, para cada link simbólico listado na linha de comando, chmodaltera as permissões do arquivo apontado. Por outro lado, chmodignora os links simbólicos encontrados durante os percursos de diretório recursivos.

No entanto, em um Mac, o chmod pode ser usado para modificar as permissões de um link simbólico usando opções como esta (de man chmod):

-h Se o arquivo for um link simbólico, altere o modo do próprio link em vez do arquivo para o qual o link aponta.

Por uma questão de exemplo, vamos supor que você esteja em uma máquina Linux para o restante desta resposta.

Se, no primeiro caso, você executar chmod -R 777 directorypara alterar recursivamente as permissões, o destino do link não será afetado, mas, se o fizer chmod 777 directory/*, será.

Se você alterar as permissões diretamente no destino do link, essas permissões continuarão (uma vez que, como dizem a página de manual e o baraboom , as permissões de link reais não são usadas para nada).

Log de teste para ilustração:

$ 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

as respostas de baraboom e peth estão corretas: os bits de permissão nos links simbólicos são irrelevantes (exceto no macOS; veja abaixo) e a alteração de permissão em um link simbólico - pela chmodferramenta de linha de comando ou pela chmod()chamada do sistema - simplesmente agirá como se foi realizado contra o alvo do link simbólico.

Para citar a descrição do sistema symlink () do SUSv4 / POSIX.1-2008, chame :

Os valores dos bits do modo de arquivo para o link simbólico criado não são especificados. Todas as interfaces especificadas pelo POSIX.1-2008 devem se comportar como se o conteúdo dos links simbólicos sempre possa ser lido, exceto que o valor dos bits do modo de arquivo retornados no campo st_mode da estrutura stat não é especificado.

Aqui, "não especificado" deixa espaço de interpretação para cada implementação. Específicos:

• No Linux (testado usando ext4fs), stat()retorna st_mode=0777, não importa qual era o umask quando o link simbólico foi criado; ls -lportanto, sempre é exibido lrwxrwxrwxpara links simbólicos.
• No macOS (HFS) e no FreeBSD (UFS e ZFS), um link simbólico tem sua própria permissão: O chmod -hcomando mencionado acima pode alterar essa permissão de link (que internamente usa uma lchown()chamada de sistema não POSIX para conseguir isso) e o stat()sistema call retorna esse valor para st_mode.

Links simbólicos no Linux e FreeBSD sempre podem ser seguidos, conforme especificado pelo POSIX. Em particular, no FreeBSD, isso significa que o modo de arquivo de um link simbólico não tem efeito algum no controle de acesso.

Por outro lado, o macOS quebra levemente o POSIX. Embora um link simbólico possa ser seguido independentemente de sua permissão de leitura, readlink()falha com EACCES(Permissão negada) se o usuário não tiver permissão de leitura:

$ 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

(Observe que a -> targetparte está ausente na saída do segundo ls -lcomando e que cat symlinkainda teve êxito e imprimiu o conteúdo do targetarquivo, mesmo que o usuário não tenha permissão de leitura symlink.)

Aparentemente, o NetBSD oferece uma opção especial de montagem denominada sympermque, se definida, causa permissões simbólicas de leitura / execução de readlink()link para controlar e atravessar a passagem.

1. solte o arquivo de link (depois de garantir que ele não seja usado por nenhum processo)
2. configure umask de maneira que as permissões de arquivo 777-umask = exigidas
3. crie o arquivo de link novamente