Por que Linux / POSIX tem lchown mas não lchmod?

Question

Parece que o Linux suporta a mudança do proprietário de um link simbólico (ou seja, lchown ), mas mudando o modo / permissão de um link simbólico (ou seja, lchmod ) é não suportado . Tanto quanto eu posso ver isso está de acordo com POSIX. No entanto, não entendo por que alguém suportaria uma dessas operações, mas não as duas. Qual é a motivação por trás disso?

    

Answer 1

Linux, como a maioria dos sistemas Unix-like (Apple OS / X sendo uma das raras exceções), ignora permissões em links simbólicos quando se trata de resolver seus alvos por exemplo.

No entanto, a propriedade de links simbólicos, como outros arquivos, é relevante quando se trata da permissão para renomear ou desvincular suas entradas em diretórios que têm o t bit definido, como /tmp .

Para poder remover ou renomear um arquivo (link simbólico ou não) em /tmp , você precisa ser o proprietário do arquivo. Essa é uma razão pela qual alguém pode querer alterar a propriedade de um link simbólico (para conceder ou remover permissão para desvincular / renomear).

$ ln -s / /tmp/x
$ rm /tmp/x
# OK removed

$ ln -s / /tmp/x
$ sudo chown -h nobody /tmp/x
$ rm /tmp/x
rm: cannot remove ‘/tmp/x’: Operation not permitted

Além disso, conforme mencionado por Mark Plotnick em sua resposta agora excluída , os aplicativos de backup e arquivamento precisam de lchown() para restaurar links simbólicos para seus donos originais. Outra opção seria trocar euid e egid antes de criar o symlink, mas isso não seria eficiente e complicaria os gerenciamentos certos no diretório em que o link simbólico é extraído.

    

Answer 2

Não há lchmod () no posix mas fchmodat () que permite definir as permissões de um symlink. Isso ainda não requer que as permissões dos links simbólicos sejam avaliadas.