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

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

linux permissions posix

— Florian Brucker
fonte

As permissões de um link simbólico são sempre lrwxrwxrwx. A chmodnão faz sentido aqui. Seguir o link leva você às permissões de destino.

— 23--15

@ott: No Linux, as permissões de um link simbólico são sempre as que você forneceu exatamente porque o Linux não suporta lchmod. Mas outros sistemas operacionais semelhantes ao Unix o suportam (por exemplo, Mac OS X ), então a questão é por que o Linux não suporta quando suporta lchown.

— Florian Brucker

Respostas:

O Linux, como a maioria dos sistemas Unix (o Apple OS / X é uma das raras exceções), ignora as permissões nos links simbólicos quando se trata de resolver seus destinos, por exemplo.

No entanto, a propriedade dos links simbólicos, como outros arquivos, é relevante quando se trata da permissão para renomear ou desvincular suas entradas em diretórios com o tbit definido, como /tmp.

Para poder remover ou renomear um arquivo (link simbólico ou não) /tmp, você precisa ser o proprietário do arquivo. Essa é uma das razões pelas quais 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, como mencionado por Mark Plotnick em sua resposta agora excluída , os aplicativos de backup e arquivamento precisam lchown()restaurar links simbólicos para seus proprietários originais. Outra opção seria alternar euid e egid antes de criar o link simbólico, mas isso não seria eficiente e complicaria o gerenciamento correto no diretório em que o link simbólico é extraído.

— Stéphane Chazelas
fonte

Não tenho certeza se essa é a motivação original, mas fornece uma razão pela qual o design é útil. Obrigado!

— Florian Brucker

Não existe lchmod () no posix, mas fchmodat () que permitiria definir as permissões de um link simbólico. Isso ainda não exige que as permissões dos links simbólicos sejam avaliadas.

— esperto
fonte

O OP sabe que não ter lchmodestá de acordo com o POSIX. O que essa resposta acrescenta que ainda não está na pergunta?

— Muru

O op perguntou por que apenas uma das funções é suportada e expliquei que praticamente ambas estão disponíveis, mas não com o nome mencionado.

— schily

Como assim? O padrão diz : Algumas implementações podem permitir alterar o modo de links simbólicos. Isso não é suportado pelas interfaces na especificação POSIX. Os sistemas com esse suporte fornecem uma interface chamada lchmod (). Para dar suporte a essas implementações, o fchmodat () possui um parâmetro flag. Tudo o que isso diz é que há um sinalizador para fchmodat que permite que a implementação altere as permissões do link simbólico. Não que isso necessariamente possa.

— muru

Correto, como as permissões de links simbólicos não são avaliadas há 35 anos, não faz sentido alterar os modos. Fchmodat () existe para ortogonsidade. A única vantagem real era futimensat (), pois os timestamps configuráveis para links simbólicos ajudam os humanos a entender uma árvore de diretórios.

— schily

@schilly, o OS / X respeita as permissões nos links simbólicos. Lá, se você não tiver permissões de leitura, não poderá resolver seus destinos.

— Stéphane Chazelas