Como configurar permissões linux para a pasta WWW?

Resumo atualizado

O diretório / var / www pertence, o root:rootque significa que ninguém pode usá-lo e é totalmente inútil. Como todos queremos um servidor da Web que realmente funcione (e ninguém deve fazer login como "root"), precisamos corrigir isso.

Apenas duas entidades precisam de acesso.

1. PHP / Perl / Ruby / Python precisam de acesso às pastas e arquivos, pois eles criam muitos deles (ie /uploads/). Essas linguagens de script devem estar em execução no nginx ou no apache (ou mesmo em alguma outra coisa como o FastCGI for PHP).

2. Os desenvolvedores

Como eles obtê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 o 777 tem permissão total de leitura / gravação / execução para proprietário / grupo / outro. Portanto, isso não parece ser necessário , pois oferece permissões completas a usuários aleatórios.

Quais permissões precisam ser usadas /var/wwwpara que:

1. Controle de fonte como git ou svn
2. Usuários de um grupo como "sites" ( ou mesmo adicionados a "www-data" )
3. Servidores como apache ou lighthttpd
4. 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 intérprete. Portanto, não há necessidade de executar permissão nos arquivos em /var/www...? Portanto, parece que a permissão correta seria o chmod -R 1660que tornaria

1. todos os arquivos compartilháveis ​​por essas quatro entidades
2. todos os arquivos não executáveis ​​por engano
3. bloquear todo mundo do diretório completamente
4. defina o modo de permissão como "fixo" 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 os arquivos acima, então não tenho certeza de quais seriam as permissões do diretório.

Atualização 2: a estrutura das pastas /var/wwwmuda drasticamente, pois uma das quatro entidades acima sempre adiciona (e às vezes remove) pastas e subpastas com muitos níveis de profundidade. Eles também criam e removem arquivos aos quais as outras três 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 (consulte a pergunta sobre ruby ​​/ php acima), eu assumiria que a 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 o item 2) e todos os outros usuários em o sistema só tem acesso de leitura.

Atualização 3: É para máquinas de desenvolvimento pessoal e servidores de empresas privadas. Nenhum "cliente da Web" aleatório como um host compartilhado.

Atualização 4: este artigo de 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 OR svn / git é executado e como alterá-los.

Atualização 5: Eu acho que finalmente encontrei uma maneira de fazer tudo isso funcionar (resposta abaixo). No entanto, não sei se essa é a maneira correta e segura de fazer isso. Portanto, eu comecei uma recompensa. A pessoa que tem o melhor método de proteger e gerenciar o diretório www vence.

Depois de mais pesquisas, parece que outra maneira (possivelmente melhor) de responder isso seria configurar a pasta www assim.

1. sudo usermod -a -G developer user1 (adicione cada usuário ao grupo de desenvolvedores)
2. sudo chgrp -R developer /var/www/site.com/ para que os desenvolvedores possam trabalhar lá
3. sudo chmod -R 2774 /var/www/site.com/ para que apenas desenvolvedores possam criar / editar arquivos (outro mundo pode ler)
4. 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 estiver 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 do grupo' para o diretório. Isso faz com que novos arquivos e subdiretórios criados nele 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:

• / var / www contém uma pasta para cada site.
• Cada site tem um proprietário designado, que é definido como o proprietário de todos os arquivos e pastas no diretório do site.
• Todos os usuários que mantêm o site são colocados em um grupo para o site.
• Este grupo é definido como o proprietário do grupo de todos os arquivos e pastas no diretório.
• Todos os arquivos ou pastas que precisam ser gravados pelo servidor da web (por exemplo, PHP) tiveram seu proprietário alterado para www-data, o usuário sob o qual o apache executa.

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. (No entanto, os daemons git / svn são uma questão diferente!) Tudo o que eu criei / clonei com o git tinha minhas permissões e a ferramenta git foi listada na /usr/binqual se encaixa nesta tese.

Permissões Git resolvidas.

As permissões de usuário parecem ser solucionáveis ​​adicionando todos os usuários que precisam acessar o diretório www ao www-datagrupo em que o apache (e o nginx) são executados.

Parece que uma resposta para esta pergunta é a seguinte:

Por padrão, /var/wwwé de propriedade de root:roote ninguém pode adicionar ou alterar arquivos lá.

1) Alterar proprietário do grupo

Primeiro, precisamos alterar o grupo de diretórios www para pertencer a "www-data" em vez do grupo "raiz"

sudo chgrp -R www-data /var/www

2) Adicione usuários ao www-data

Em seguida, precisamos adicionar o usuário atual (e qualquer outra pessoa) ao grupo www-data

sudo usermod -a -G www-data demousername

3) diretório www CHMOD

Altere as permissões para que APENAS o proprietário (raiz) e todos os usuários do grupo "www-data" possam rwx (ler / gravar / executar) arquivos e diretórios ( ninguém mais poderá acessá-lo ).

sudo chmod -R 2770 /var/www

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 é uma 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 de grupo dos arquivos recém-criados será definido como o mesmo do diretório pai. Para algo mais, você precisa procurar em 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á hospedando na web com vários clientes e não deseja que eles vejam os arquivos uns dos outros, use um grupo comum "webcusts" para todos esses usuários e um modo de diretório 0705. Em seguida, os arquivos são exibidos por o processo do servidor da web ( não em "webcusts") verá as outras permissões e será permitido; os clientes não podem ver os arquivos dos outros e os usuários podem mexer com 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 (de qualquer forma, boas práticas, para vários usuários em um host, para prestação de contas). Caso contrário, os clientes poderão mexer nos arquivos uns dos outros, solicitando um CGI.

No entanto, se o usuário em tempo de execução de um site for o mesmo que o proprietário do site, você terá problemas para não poder proteger o conteúdo de agressores no caso de uma falha de segurança no script. É aí que os hosts dedicados vencem, para que você possa ter um usuário em tempo de execução diferente do proprietário do conteúdo estático e não precisar se preocupar tanto com a interação com outros usuários.

Acredito que a melhor maneira de fazer isso é usar ACLs Posix. 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 é, em geral, 755/644. Enquanto para diretórios e arquivos o grupo precisa de acesso de gravação, o mod é 775/664. Suponha que o paddy seja o desenvolvedor. No total, isso faz:

chown -R paddy:www-data /var/www/websiteindevelopment
chmod -R 755 /var/www/websiteindevelopment
chmod -R 775 /var/www/websiteindevelopment/directorywritablebygroup
find /var/www/websiteindevelopment -type f -perm 755 -print -exec chmod 644 {} \;  
find /var/www/websiteindevelopment -type f -perm 775 -print -exec chmod 664 {} \;

Adicionando à resposta do @ Xeoncross, acho que seria bom configurar permissões em arquivos e diretórios separadamente.

sudo find /var/www -type d -exec chmod 775 {} \;  # Change permissions of directories to rwxrwxr-x
sudo find /var/www -type f -exec chmod 664 {} \;  # Change file permissions to rw-rw-r--

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 é mais necessário.

Também permitirá que os desenvolvedores criem e modifiquem arquivos de código (leia arquivos HTML, PHP e similares). Mas, ainda permitirá apenas o acesso somente leitura para todos os outros.