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


Vamos dizer que você tem essa estrutura:

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

file3 é um link para outro file3 em algum outro lugar do sistema.

Agora digamos que eu chmod 777 o diretório e todo o conteúdo dentro dele. Minha file3 dentro /tmp receber essas permissões? Além disso, digamos que temos a mesma situação, mas invertemos.

/tmp/file3 -> /directory/file3

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


80


origem


As permissões afetam apenas o arquivo, não o link simbólico. - baraboom


Respostas:


Depende de como você chama chmod e a plataforma em que você está correndo.

Por exemplo, em um sistema Linux, man chmod diz isso:

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   já que as permissões de links simbólicos nunca são usadas. Contudo,   para cada link simbólico listado na linha de comando, chmod muda o   permissões do arquivo apontado. Em contraste, chmod ignora   Links simbólicos encontrados durante travessias de diretório recursivas.

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

-h Se o arquivo é um link simbólico, mude o modo do link   em vez do arquivo para o qual o link aponta.

Por exemplo, vamos supor que você está em uma máquina Linux pelo resto desta resposta.

Se no primeiro caso você correr chmod -R 777 directory para alterar de forma recursiva as permissões, o destino do link não será afetado, mas se você chmod 777 directory/*, será.

Se você alterar as permissões diretamente no destino do link, essas permissões serão executadas (como man page e baraboom digamos, 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

80



Isso foi uma surpresa para mim também. Próxima pergunta: quem faz as permissões em um symlink significar? - Edward Falk
As permissões de link simbólico do @EdwardFalk não são não restritivas, pois tudo precisa ser capaz de percorrê-lo para obter as permissões do arquivo vinculado. - Walf


As respostas de baraboom e peth estão corretas: Os bits de permissão nos próprios links simbólicos são irrelevantes (exceto no macOS; veja abaixo) e a alteração da permissão em um link simbólico - pelo chmod ferramenta de linha de comando ou pelo chmod() chamada do sistema - simplesmente agirá como se fosse executada contra o destino do link simbólico.

Citar a descrição do SUSv4 / POSIX.1-2008 da chamada de sistema symlink ():

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 comportar-se como se o conteúdo dos links simbólicos pudesse sempre ser lido, exceto que o valor dos bits do modo de arquivo retornado no st_mode campo do stat estrutura não é especificada.

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

  • No Linux (testado usando ext4fs), stat() retorna st_mode=0777, não importa qual seja a umask quando o symlink foi criado; ls -l portanto, sempre exibe lrwxrwxrwx para links simbólicos.
  • No macOS (HFS) e FreeBSD (ambos UFS e ZFS), um link simbólico tem sua própria permissão: chmod -h comando mencionado acima pode alterar esta permissão de link (que usa internamente um não POSIX lchown()chamada de sistema para o conseguir), e stat() chamada do sistema retorna este 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 interrompe ligeiramente 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

(Note que o -> target porção está faltando na saída do segundo ls -l comando, e que cat symlink ainda conseguiu e imprimiu o conteúdo do target arquivo mesmo que o usuário não tenha permissão de leitura symlink.)

O NetBSD aparentemente oferece uma opção de montagem especial chamada symperm que, se definido, faz com que permissões de leitura / execução de link simbólico controlem readlink() e passagem de link.


2





  1. Solte o arquivo de link (depois de garantir que ele não seja usado por nenhum processo)
  2. defina umask de tal forma que o 777-umask = permissões de arquivo necessárias
  3. criar o arquivo de link novamente

-1



Como isso responde a pergunta? - jww