De chown (2):
Only a privileged process (Linux: one with the CAP_CHOWN capability) may change the owner of a file. The owner of a file may change the group of the file to any group of which that owner is a member. A privileged process (Linux: with CAP_CHOWN) may change the group arbitrarily.
Qual é o motivo dessa restrição? Por que um usuário não privilegiado não pode alterar a propriedade de um arquivo que ele possui (ou seja, nenhum / etc / shadow)?
$ touch blah
$ chown root:root blah
chown: changing ownership of 'blah': Operation not permitted
Ao permitir que os usuários "ofereçam" arquivos, você entra em conflito com vários recursos do sistema operacional. Tais como:
Taking up another user's disk quota.
Impersonating another user (or even root) via setuid.
Having insufficient privileges to undo a mistaken chown.
Making it appear that someone else had created a given file.
Setting up cron jobs to run on other user's accounts.
And many more...
É apenas uma escolha pessoal dos projetistas linux não permitir isso - todas as razões de pseudo-segurança, dadas , são ilusórias, já que existem sistemas unix que permitem isso.
Acho que esta funcionalidade se deve ao fato de o comportamento do seu unix ter seguido ou não o "System-V" (AT & T) ou o Unix de Berkeley (BSD) ...
Quanto a outras questões de segurança mencionadas:
Representando outro usuário (ou mesmo root) via setuid.
Sem problemas: Alterar o 'proprietário' limpa qualquer bit 'setXid' (U / G)
Ter privilégios insuficientes para desfazer um chown errado
Não é realmente um 'risco de segurança', MAS, pode ser em sistemas que permitir alterar usuário, você pode alterá-lo de volta se estiver em um diretório que você possui, caso contrário: 'tenha cuidado'!
Faz parecer que alguém criou um determinado arquivo.
Ele ainda estaria em um diretório que pode ser gravado por você. Ou seja você não pode movê-lo para o seu homedir, a menos que ele esteja aberto para escrever para o seu grupo ou para todos (ou especificamente se as ACLs estiverem disponíveis).
Configurando trabalhos cron para serem executados em contas de outros usuários.
Novamente, isso não funcionaria - já que os crondirs são de propriedade do usuário e não estão definidos para serem legíveis por outros usuários, e muito menos graváveis.
se alguém puder alterar a propriedade, qualquer pessoa poderá alterar as permissões para obter acesso a qualquer arquivo no sistema.
Não: somente se o usuário 'possui' o diretório que contém o arquivo. Ou seja Eu posso dar um arquivo chamado 'passwd' para root, mas eu não poderia movê-lo para / etc / a menos que eu tenha permissão de escrita para / etc /.
quotas
Um ponto potencialmente válido - SE você usa cotas, mas parece que seria fácil detectar se você somaria o espaço em disco por home-dir; O único problema seria em dirs que são graváveis por vários usuários. Nesse caso, talvez passando pelo dono desse 'dir'. MAIO é o caso daqueles sistemas que suportam arquivos 'doação', que você só pode fazer isso em diretórios que você 'possui', mas já faz muito tempo desde que eu realmente estive um sistema que permite isso, então não me lembro das restrições exatas.
Eu pareço lembrar que existe algum 'trade-off' por permitir 'dar arquivos' ... por exemplo - em sistemas que permitiam isso, algo não era permitido que o linux permitisse, mas não conseguia lembrar o que estava errado ...
Eu diria que a resposta acima deve ser desmarcada como resposta, pois NÃO é a resposta real. É mais uma decisão de design - eu simplesmente não sei qual foi o tradeoff (s).
Pode haver problemas de segurança não levantados acima que seriam preocupações válidas, mas os acima não são válidos.
IMO, deve ser um 'valor' configurável pelo sistema em "/ proc", mas, em geral, acho que a maioria das pessoas não se importa muito.
Se houvesse uma grande necessidade, o 'chown' poderia ser melhorado e modificado para permitir sua segurança e então configurar w / setuid 'root' para permitir que ele implementasse tal política.
Bem, se alguém puder alterar a propriedade, qualquer pessoa poderá alterar as permissões para obter acesso a qualquer arquivo no sistema. Isso é ruim não apenas do ponto de vista de malware (não é necessário sudo), mas do ponto de vista de um administrador de sistema. Se qualquer um dos usuários puder alterar algum dos arquivos, as permissões de arquivo serão inúteis.
Porque o usuário pode escapar das cotas do sistema de arquivos. Se eu tiver uma cota de 100MB e você tiver uma cota de 100MB, posso fazer upload de 100MB, chmod a + r, chown you e, em seguida, fazer upload de outros 100MB.