O comportamento chmod está errado para links simbólicos?

Question

Recentemente, tivemos um problema em uma caixa do Red Hat Linux com muitos usuários: o binário /usr/bin/sudo perdeu seu sticky bit. O trabalho foi bloqueado até que o usuário raiz o conserte (precisamos de sudo para implantar e testar).

O motivo deste detalhamento foi ... symlink $HOME/bin/s apontando para /usr/bin/sudo . Eu pensei que ter mais um alias do bash não é bom e o symlink é uma solução mais simples que funciona com qualquer shell, então eu criei o symlink $HOME/bin/s apontando para /usr/bin/sudo . Então, um cara copiou meu $HOME/bin para seu $HOME e "apenas no caso" chamado sudo chmod 755 $HOME/bin/* . Como resultado, /usr/bin/sudo tem permissões de 0755 em vez de 4111. Agora está consertado, o root fez o login e restaurou as permissões para o sudo.

man chmod (Red Hat, Ubuntu):

  chmod never changes the permissions of symbolic links; the chmod system
  call  cannot change their permissions.  This is not a problem since the
  permissions of symbolic links are never used.  However, for  each  sym-
  bolic link listed on the command line, chmod changes the permissions of
  the pointed-to file.

Minha pergunta é: foi minha culpa, porque eu nunca deveria criar links simbólicos apontando para binários ou o comportamento chmod está errado e não deveria alterar permissões de arquivos apontados por links simbólicos? Por que esse é o comportamento de chmod ? Faz algum sentido?

    

Answer 1

Fazer links simbólicos para binários é bom; verifique /bin e /usr/bin e você certamente encontrará vários aliases. O problema aqui é usar sudo sem entender completamente as consequências. Felizmente, não houve danos permanentes e você aprendeu uma lição importante. Quando você estiver apenas certificando-se de que são executáveis, use a+x ou mesmo u+x . Como uther diz , você provavelmente estaria melhor com um alias mesmo assim.

A página man explica por que essa é a ação - as permissões sobre links simbólicos não importam, apenas nos arquivos que elas resolvem. Mais frequentemente, o usuário deseja alterar os atributos do arquivo para o qual o link aponta.

Além disso, acabei de verificar as man pages chmod() syscall para Linux e BSD. Ambos retornam erros para loops de links simbólicos, o que implica que esse comportamento de alterar o perms do arquivo e não o link é determinado e aplicado no nível do kernel.

    

Answer 2

Mikel já disse isso, mas é tipo de enterrado em sua resposta, então: a coisa real que foi feito de errado é

sudo chmod 755 $HOME/bin/*     # <<<< highly suspicious!

É bastante bizarro precisar de permissões de superusuário para agir em arquivos em seu diretório pessoal. Se o cara descobrisse que ele não tinha permissão para fazer alguma coisa em seu próprio diretório, ele deveria ter investigado a situação e não executar cegamente o sudo. Para reiterar: não execute cegamente o sudo . Se o cara tivesse executado chmod 755 $HOME/bin/* , ele teria visto a mensagem de erro chmod: changing permissions of / home / guy / bin / s ': operação não permitida'.

A propósito, eu não recomendo fazer s um alias para sudo (e se você precisar fazer isso, eu recomendo que você use um alias de shell e não um link simbólico: não há sentido nesse nome estar disponível para scripts). sudo não é uma operação benigna, você pode digitar três caracteres extras ao executá-lo. Dar um apelido de um caractere aumenta os riscos de erros de digitação.

É um pouco surpreendente que chmod atue no destino dos links simbólicos, quando a maioria das operações nos metadados atua no próprio link. No entanto, os links simbólicos não têm permissões úteis: eles nunca são gravados (criados e sobrescritos) ou executados, e raramente há motivo para ocultar o alvo. As variantes Unix diferem quanto a se chmod afeta os links simbólicos (não suportados por todos os sistemas), seus destinos ou nenhum deles. No Linux, chmod afeta o alvo.

    

Answer 3

Concordo que não faz muito sentido se você pensar em um symlink como um link simbólico.

Mas se você acha que um link simbólico é como um link físico, faz mais sentido.

A primeira linha de man 7 symlink diz exatamente isso

Symbolic links are files that act as pointers to other files. 
To understand their behavior, you must first understand how hard links work.

A hard link to a file is indistinguishable from the original file because
it is a reference to the object underlying the original filename.
[...]
Changes to a file are independent of the name used to reference the file. 

Assim, com um link físico, quando você altera as permissões no arquivo por meio de qualquer nome, as permissões subjacentes são alteradas para todos os nomes.

A maioria das ferramentas tenta seguir links simbólicos, para que você possa fingir que é realmente um link físico.

Except as noted below, commands follow symbolic links named as
command-line arguments.

The mv(1) and rm(1) commands do not follow symbolic links named as
arguments, but respectively attempt to rename and delete them. 

Commands traversing a file tree [...]

Criar links simbólicos (ou links físicos) para binários às vezes é útil, mas, como você acabou de descobrir, ele cria alguns casos que podem causar problemas.

Dito isso, acho que o maior problema aqui foi usar sudo quando não foi necessário.

Se o outro usuário tiver acesso de leitura ao seu ~/bin , então sudo foi completamente desnecessário.

Ou, se eles não tiverem acesso, você poderá concedê-lo (por exemplo, usando chmod g+rx $HOME/bin ) ou fornecer-lhes um tarball.

Se você ainda acha que usar sudo é uma boa ideia, veja algumas alternativas:

sudo chown -h $USER $HOME/bin/*
chmod 755 $HOME/bin/*

-h diz chown para não seguir os links simbólicos

chmod -R 755 $HOME/bin/*

-R diz ao chmod para "percorrer a árvore de arquivos", o que faz com que ele ignore os links simbólicos como sugerido acima em man 7 symlink .

sudo find $HOME/bin/ -type f -exec chmod 755 {} +

-type f diz find para não executar o comando exec (neste caso chmod ) em links simbólicos.

# as user 2
cd ~user2/bin
sudo tar -C ~user1/bin -cf - . | tar -xf -

executa a raiz tar -cf as para que você possa ver todos os arquivos, mas executa tar -xf como usuário2, o que faz com que os arquivos extraídos sejam de propriedade do usuário2.

    

Answer 4

Criar um alias e criar um link simbólico para um arquivo é válido (embora os aliases sejam geralmente preferidos). Eu não acho que há uma "falha" nessa situação. Esse é o comportamento de chmod , então agora você sabe como chmod funciona em arquivos com links simbólicos (ele não mudou) e pode evitar fazer isso no futuro. Se isso acontecer de novo, você sabe como consertar isso.