Como lidar com o problema de permissão do usuário?

Question

Criamos um aplicativo da web de aplicativo de gerenciamento de ativos usando php . Este aplicativo permite aos usuários navegar, fazer upload, renomear, substituir ativos (arquivos binários, como imagens e modelos 3D)

Nós desenvolvemos em ambiente Windows e tudo funciona bem, mas quando hospedamos no servidor linux (joyent) estamos rodando com problemas de permissão em alguns cenários. Abaixo está a configuração do ambiente

Nossa pasta raiz da web pública está localizada em home/jill/web/public (webroot). Todos os recursos estão localizados em home/jill/web/public/assets (ativos raiz) e também em subpastas

Abaixo estão os casos de uso da maneira como lidamos com o gerenciamento de ativos -

1. Upload em massa de todos os ativos usando o programa ftp com o usuário ftp (ftpuser)
2. Fazer upload em massa de todos os recursos usando o usuário webadmin (jill), que é proprietário de home/jill/web/public
3. Carregar recursos usando o aplicativo da web (o usuário padrão da web é www)

Em todos os casos de uso acima, também sobrescrevemos ativos com os arquivos modificados mais recentes. Agora há um aplicativo flash (jogo) hospedado na webroot que acessa todos os ativos e cargas no aplicativo.

Agora, recebemos erros de permissão quando tentamos substituir / atualizar o arquivo usando um ID de usuário diferente do que é originalmente criado por um usuário diferente.

Exemplo: Tente sobrescrever um arquivo usando o aplicativo da web que foi carregado inicialmente usando o usuário ftp e vice-versa

Qual é a maneira como podemos lidar com este cenário para que qualquer arquivo ou diretório criado sob webroot \ assets por qualquer usuário possa ser modificado por qualquer usuário?

Eu sou um desenvolvedor não familiarizado com unix / linux, mas acho que é algo a ver com o tratamento de grupos e permissão de grupo, mas não tenho certeza de como definir?

    

Answer 1

Existem basicamente duas coisas:

1) permissões nos arquivos e diretório que já existem:

A resposta de Alan cobre principalmente isso: crie um grupo especial ao qual você adiciona todos os usuários que possam precisar gravar os arquivos. Certifique-se de que o diretório em que você está enviando seja ele próprio gravável para esse grupo: chmod 0775 path/to/the/directory . Quaisquer arquivos existentes precisarão de chmod 0664 .

Os números "mágicos" são octal e representam trios: setuid, permissões de proprietário, permissões de grupo, permissões mundiais. O setuid não é de seu interesse, mantenha 0 . para os outros, o número octal (0-7) informa as permissões: se o 0º bit estiver ligado, o arquivo / diretório é executável (para o diretório significa que ele pode ser digitado), se o primeiro bit estiver gravado, o 2º bit é gerenciar legibilidade - por exemplo 0754 significaria que o proprietário tem todas as permissões, os membros do grupo podem ler e executar, e o resto do mundo só pode lê-lo. Você pode escrever o mesmo com mnemônicos como este: chmod u=rwx,g=rx,o=r . Veja man chmod um sistema Linux para explicação detalhada.

2) permissões em arquivos recém-criados:

Procure a configuração umask em qualquer que seja o envio. Isso diz com quais permissões novos arquivos são criados. Novamente, veja man umask no sistema Linux / UNIX, a idéia é que quaisquer bits definidos em umask (a mesma notação que para chmod explicada acima) são excluídos das permissões em arquivos recém-criados - por exemplo, se você definir umask to 0023 , seus arquivos serão criados com todas as permissões, não graváveis para o grupo padrão e não graváveis nem executáveis por qualquer outra pessoa. Geralmente é uma má idéia definir o 0º bit aqui, já que na criação do diretório torna-o não executável que bloqueia a entrada do diretório (para o conjunto de usuários para o qual o bit está configurado, no 0023 example para " qualquer outra pessoa ").

Além disso, pode valer a pena atribuir ACLs padrão ao diretório, se o sistema de arquivos subjacente os suportar. Isso permitiria um controle de acesso mais refinado (ACL significa Access Control List, semelhante ao Windows One). Veja man setfacl para mais informações.

AVISO DE GRANDE GORDURA: Não é uma boa ideia tornar os arquivos mundialmente graváveis! Mantenha os direitos no mínimo que funciona.

    

Answer 2

Tente o seguinte. (Isso foi testado no Lubuntu)

Vá para home / jill / web / public e faça: ls -la

Ele mostrará os detalhes dos arquivos e pastas lá. Um deles será ativo (isto é apenas um exemplo, os detalhes dos seus recursos serão diferentes):

-rw-r----- 1 user group 9275204 Jun 13 15:27 assets

A ideia é criar um novo grupo e torná-lo o proprietário dos recursos e, em seguida, adicionar todos os usuários a esse grupo.

Crie um novo grupo no servidor.

groupadd assetgroup

Adicione os usuários ao novo grupo:

usermod -a -G assetgroup ftpuser
usermod -a -G assetgroup jill
usermod -a -G assetgroup www

Altere a propriedade da pasta assets para o assetgroup . (-R é para alteração recursiva)

sudo chgrp -R assetgroup assets/