Resumo atualizado
O diretório /var/www é de propriedade, root:root
o que significa que ninguém pode usá-lo e é totalmente inútil. Já que todos nós queremos um servidor web que realmente funcione (e ninguém deve estar logando como "root"), então precisamos corrigir isso.
Apenas duas entidades precisam de acesso.
PHP/Perl/Ruby/Python todos precisam de acesso às pastas e arquivos, pois eles criam muitos deles (ou seja,
/uploads/
). Essas linguagens de script devem ser executadas em nginx ou apache (ou mesmo alguma outra coisa como FastCGI para PHP).Os desenvolvedores
Como eles têm acesso? Eu sei que alguém, em algum lugar, já fez isso antes. No entanto, com muitos bilhões de sites por aí, você pensaria que haveria mais informações sobre esse tópico.
Eu sei que 777 é permissão total de leitura/gravação/execução para proprietário/grupo/outro. Portanto, isso não parece ser necessário , pois fornece permissões totais a usuários aleatórios.
Quais permissões precisam ser usadas /var/www
para que:
- Controle de origem como git ou svn
- Usuários em um grupo como "sites" ( ou mesmo adicionados a "www-data" )
- Servidores como apache ou lighthttpd
- E PHP/Perl/Ruby
todos podem ler, criar e executar arquivos (e diretórios) lá?
Se eu estiver correto, os scripts Ruby e PHP não são "executados" diretamente - mas passados para um interpretador. Portanto, não há necessidade de permissão de execução em arquivos em /var/www
...? Portanto, parece que a permissão correta seria o chmod -R 1660
que faria
- todos os arquivos compartilháveis por essas quatro entidades
- todos os arquivos não executáveis por engano
- bloquear todos os outros do diretório completamente
- defina o modo de permissão como "pegajoso" para todos os arquivos futuros
Isso está correto?
Atualização 1: Acabei de perceber que arquivos e diretórios podem precisar de permissões diferentes - eu estava falando sobre arquivos acima, então não tenho certeza de quais seriam as permissões de diretório.
Atualização 2: A estrutura de pastas /var/www
muda drasticamente, pois uma das quatro entidades acima está sempre adicionando (e às vezes removendo) pastas e subpastas com muitos níveis de profundidade. Eles também criam e removem arquivos aos quais as outras 3 entidades podem precisar de acesso de leitura/gravação. Portanto, as permissões precisam fazer as quatro coisas acima para arquivos e diretórios. Como nenhum deles deve precisar de permissão de execução (veja a pergunta sobre ruby/php acima), eu diria que essa rw-rw-r--
permissão seria tudo o que é necessário e completamente seguro, pois essas quatro entidades são executadas por pessoal confiável (consulte # 2) e todos os outros usuários em o sistema só tem acesso de leitura.
Atualização 3: Isso é para máquinas de desenvolvimento pessoal e servidores de empresas privadas. Não há "clientes da web" aleatórios como um host compartilhado.
Atualização 4: Este artigo do slicehost parece ser o melhor para explicar o que é necessário para configurar permissões para sua pasta www. No entanto, não tenho certeza de qual usuário ou grupo apache/nginx com PHP OU svn/git é executado e como alterá-los.
Atualização 5: Eu (eu acho) finalmente encontrei uma maneira de fazer tudo isso funcionar (resposta abaixo). No entanto, não sei se esta é a maneira correta e segura de fazer isso. Portanto, eu comecei uma recompensa. A pessoa que tiver o melhor método para proteger e gerenciar o diretório www vence.
Depois de mais pesquisas, parece que outra (possivelmente melhor maneira) de responder a isso seria configurar a pasta www assim.
sudo usermod -a -G developer user1
(adicione cada usuário ao grupo de desenvolvedores)sudo chgrp -R developer /var/www/site.com/
para que os desenvolvedores possam trabalhar lásudo chmod -R 2774 /var/www/site.com/
para que apenas desenvolvedores possam criar/editar arquivos (outros/mundos podem ler)sudo chgrp -R www-data /var/www/site.com/uploads
para que www-data (apache/nginx) possa criar uploads.Como
git
é executado como qualquer usuário que o esteja chamando, enquanto o usuário estiver no grupo "desenvolvedor", ele poderá criar pastas, editar arquivos PHP e gerenciar o repositório git.Nota: Na etapa (3): '2' em 2774 significa 'definir ID de grupo' para o diretório. Isso faz com que novos arquivos e subdiretórios criados dentro dele herdem o ID do grupo do diretório pai (em vez do grupo principal do usuário) Referência: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories
Não tenho certeza se está "certo", mas aqui está o que faço no meu servidor:
Lembre-se de que você deve ter o bit de execução ativado nos diretórios para poder listar o conteúdo.
Depois de fazer mais pesquisas, parece que as FERRAMENTAS git/svn NÃO são um problema, pois são executadas como qualquer usuário que as esteja usando. (Entretanto, os daemons git/svn são uma questão diferente!) Tudo que eu criei/clonei com git teve minhas permissões e a ferramenta git foi listada no
/usr/bin
que se encaixa nesta tese.Permissões do Git resolvidas.
As permissões de usuário parecem ser solucionáveis adicionando todos os usuários que precisam de acesso ao diretório www ao
www-data
grupo em que o apache (e o nginx) são executados.Então, parece que uma resposta para essa pergunta é assim:
Por padrão
/var/www
é de propriedaderoot:root
e ninguém pode adicionar ou alterar arquivos lá.1) Alterar o proprietário do grupo
Primeiro, precisamos alterar o grupo de diretórios www para pertencer ao grupo "www-data" em vez do grupo "root"
2) Adicione usuários a www-data
Em seguida, precisamos adicionar o usuário atual (e qualquer outra pessoa) ao grupo www-data
3) Diretório CHMOD www
Altere as permissões para que SOMENTE o proprietário (root) e todos os usuários do grupo "www-data" possam rwx (ler/gravar/executar) arquivos e diretórios ( ninguém mais deve poder acessá-lo ).
Agora todos os arquivos e diretórios criados por qualquer usuário que tenha acesso (ou seja, no grupo "www-data") serão legíveis/graváveis pelo apache e, portanto, pelo php.
Isso está correto? E os arquivos criados pelo PHP/Ruby - os usuários do www-data podem acessá-los?
A aderência não é herança de permissões. A aderência em um diretório significa que apenas o proprietário de um arquivo, ou o proprietário do diretório, pode renomear ou excluir esse arquivo no diretório, apesar das permissões dizerem o contrário. Assim 1777 em /tmp/.
No Unix clássico, não há herança de permissões com base no sistema de arquivos, apenas no umask do processo atual. No *BSD, ou Linux com setgid no diretório, o campo do grupo de arquivos recém-criados será igual ao do diretório pai. Para qualquer coisa mais, você precisa examinar as ACLs, com a ACL 'padrão' nos diretórios, que permitem que você tenha permissões herdadas.
Você deve começar definindo: * quais usuários têm acesso ao sistema * qual é o seu modelo de ameaça
Por exemplo, se você está fazendo hospedagem na web com vários clientes e não quer que eles vejam os arquivos uns dos outros, então você pode usar um grupo comum "webcusts" para todos esses usuários e um modo de diretório de 0705. Então os arquivos servidos por o processo do servidor web ( não em "webcusts") verá as outras permissões e será permitido; os clientes não podem ver os arquivos uns dos outros e os usuários podem mexer em seus próprios arquivos. No entanto, isso significa que, no momento em que você permite CGI ou PHP, você precisa garantir que os processos sejam executados como o usuário específico (boa prática de qualquer maneira, para vários usuários em um host, para responsabilidade). Caso contrário, os clientes podem mexer nos arquivos uns dos outros fazendo com que um CGI o faça.
No entanto, se o usuário de tempo de execução de um site for o mesmo que o proprietário do site, você terá problemas por não poder proteger o conteúdo de invasores no caso de uma falha de segurança no script. É aí que os hosts dedicados ganham, para que você possa ter um usuário em tempo de execução distinto do proprietário do conteúdo estático e não precisar se preocupar tanto com a interação com outros usuários.
Eu acredito que a melhor maneira de fazer isso é usando Posix ACLs. Eles são confortáveis para trabalhar e oferecem toda a funcionalidade que você precisa.
http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs
O proprietário do arquivo deve ser a pessoa que o cria, enquanto o grupo deve ser www-data. O modo para diretórios/arquivos é então em geral 755/644. Enquanto para diretórios e arquivos o grupo precisa de acesso de gravação, o mod é 775/664. Suponha que paddy seja o desenvolvedor. Ao todo, isso faz:
Adicionando à resposta do @Xeoncross, acho que seria bom configurar permissões em arquivos e diretórios separadamente.
Isso permitirá que os desenvolvedores criem e modifiquem diretórios em /var/www. O que parece importante porque os desenvolvedores podem precisar criar diretórios adicionais ou remover um diretório que não seja mais necessário.
Ele também permitirá que os desenvolvedores criem e modifiquem arquivos de código (leia arquivos HTML, PHP e similares). Mas, ainda permitirá apenas acesso somente leitura para todos os outros.