Acho que a dificuldade é que os diretórios pessoais não são publicamente executáveis em seu ambiente.
Você pode colocar uma lista de controle de acesso em todos os diretórios home que dão permissão específica de execução de usuário ou grupo ao diretório . O servidor web poderá então potencialmente acessar qualquer arquivo nos diretórios home dos usuários, o que pode fornecer maneiras de escalar privilégios (pelo menos, isso ampliará o impacto de uma vulnerabilidade de acesso a arquivos locais). Por exemplo, no Solaris ou no Linux, certifique-se de que o sistema de arquivos inicial esteja montado com a opção acl
e execute
setfacl -m user:www-data:x /home/*
(integre isso na configuração de criação da sua conta). Em seguida, informe aos usuários que o diretório ~/public_html
deve ser legível pelo usuário www-data
; eles podem executar este comando:
setfacl -R -m default:user:www-data:rx ~/public_html
setfacl -R -m user:www-data:rx ~/public_html
Outra possibilidade é montar todos os diretórios public_html
dos usuários em um local separado no sistema de arquivos. Essa abordagem tem a vantagem de que as permissões nos diretórios iniciais não importam; permite até mesmo que o servidor da web execute o chroooted. No Linux, você pode fazer isso em um diretório inicial:
mount --bind /home/joe/public_html /srv/homepages/joe
O diretório public_html
e seu conteúdo ainda precisam ser disponibilizados para www-data
.
Uma variante no método de montagem de ligação do Linux usa o sistema de arquivos bindfs . Esse método funciona em qualquer sistema operacional que ofereça suporte a bindfs (que é a maioria dos unices) e não exige nenhuma configuração de ACL, com o custo de que qualquer arquivo em public_html
será disponibilizado para leitura pelo servidor da Web.
bindfs -u www-data -p 500 /home/joe/public_html /srv/homepages/joe