Apache não segue links simbólicos (403 Proibido)

90

Estou tendo problemas para configurar o Apache no Ubuntu. Tenho seguido este guia .

# /usr/sbin/apache2 -v
Server version: Apache/2.2.17 (Ubuntu)
Server built:   Feb 22 2011 18:33:02

Meu diretório público, / var / www, pode servir e executar com sucesso as páginas PHP colocadas nele. No entanto, quero criar um link simbólico em / var / www que aponte para um diretório em minha pasta pessoal e veicule páginas lá.

[root /var/www]# ll
total 36
drwxr-xr-x  3 root root 4096 2011-09-11 14:22 .
drwxr-xr-x 14 root root 4096 2011-06-04 22:49 ..
lrwxrwxrwx  1 root root   16 2011-09-11 13:21 about -> /root/site/about

Quando tento acessar / sobre no navegador, recebo 

Forbidden

You don't have permission to access /about on this server.

Pelo que sei, concedi privilégios suficientes para os arquivos que desejo servir:

[root ~/site/about]# ll
total 24
drwxr-xr-x 5 root root 4096 2011-09-11 13:20 .
drwxr--r-- 3 root root 4096 2011-09-11 13:19 ..
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 contact
-rwxr-xr-x 1 root root 1090 2011-09-11 13:19 index.php
drwxr-xr-x 2 root root 4096 2011-09-11 13:20 me
drwxr-xr-x 2 root root 4096 2011-09-11 13:21 resume

Estou ciente da opção FollowSymLinks e acredito que esteja definida em meu arquivo / etc / apache2 / sites-enabled / 000-default:

DocumentRoot /var/www
<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>
<Directory /var/www/>
    Options FollowSymLinks Indexes MultiViews
    AllowOverride None
    Order allow,deny
    allow from all
</Directory>

Alguma ideia do que posso estar perdendo?

apache configuration apache2 symlink Tim
fonte

Respostas:

126

Verifique se o Apache possui direitos de execução para /root, /root/sitee /root/site/about.

Corre:

chmod o+x /root /root/site /root/site/about
palacsinto
fonte
8
Muito obrigado ... Não percebi que os diretórios pai também tinham que ser executáveis.
Tim
39
Bem, eu não estou dizendo que não vai funcionar, mas em geral, colocar o + x em / root não é uma boa ideia;)
Michal Rzemieniecki
11
Michal está certo. Descobri que poderia usar ACLs (no Mac, pelo menos) :, chmod -R +a "_www allow list,search,readattr" /root /root/site /root/site/aboutque concede essas permissões apenas ao aplicativo apache (_www), que é um pouco mais seguro do que "outro".
James S
1
No Mac OS (10.9.4) meu ~ / Documents não tinha direitos de execução e eu tinha um repositório git onde ele hospedava os arquivos do meu site. Conceder chmod o + x em ~ / Documents resolveu o problema! Obrigado!
Ernani Joppert
1
Finalmente consegui a resposta! Obrigado.
whoan
21

O erro 403 também pode ser causado por um sistema de arquivos criptografado, por exemplo, um link simbólico para uma pasta pessoal criptografada .

Se o seu link simbólico aponta para a pasta criptografada, o usuário apache (por exemplo, www-data) não pode acessar o conteúdo, mesmo se as permissões do apache e do arquivo / pasta estiverem definidas corretamente. O acesso do usuário www-data pode ser testado com tal chamada:

sudo -u www-data ls -l /var/www/html/<your symlink>/

Existem alternativas / soluções para isso, por exemplo, adicionar o usuário www-data ao seu grupo privado (expõe os dados criptografados ao usuário da web) ou configurando uma pasta rsynced não criptografada (provavelmente bastante segura). Eu provavelmente irei para uma solução rsync durante o desenvolvimento.

/ubuntu/633625/public-folder-in-an-encrypted-home-directory

Uma ferramenta conveniente para meus objetivos é o lsyncd . Isso me permite trabalhar diretamente na minha pasta de início criptografada e ser capaz de ver as alterações quase que instantaneamente na página da web do apache. A sincronização é acionada por mudanças no sistema de arquivos, chamando um rsync. Como estou trabalhando apenas em páginas e scripts pequenos da web, a sincronização é muito rápida. Decidi usar um pequeno atraso de 1 segundo antes do rsync ser iniciado, embora seja possível definir um atraso de 0 segundos .

Instalando lsyncd (no Ubuntu):

sudo apt-get install lsyncd

Iniciando o serviço de segundo plano:

lsyncd -delay 1 -rsync /home/<me>/<work folder>/ /var/www/html/<web folder>/
user3811904
fonte
3
Essa sudo -u www-data ...é uma ótima maneira de verificar se há um problema de permissão! Observe que o usuário pode ser www-data, apache ou qualquer outra coisa, dependendo da sua distribuição.
mkasberg de
Arghh, finalmente! Eu já estava duvidando de minhas habilidades mais básicas!
Kalabalik
Perdi horas para isso e foi criptografia no final!
myol
15

Eu estava tendo um problema semelhante que não conseguia resolver por muito tempo no meu novo servidor. Além da resposta do palacsint, uma boa pergunta é: você está usando o Apache 2.4? No Apache 2.4 há um mecanismo diferente para definir as permissões que não funcionam quando feito usando a configuração acima, então usei a solução explicada nesta postagem do blog .

Basicamente, o que eu precisava fazer era converter meu arquivo de configuração de:

Alias /demo /usr/demo/html

<Directory "/usr/demo/html">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    allow from all

</Directory>

para:

Alias /demo /usr/demo/html

<Directory "/usr/demo/html">
    Options FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Observe como as linhas de pedido e permissão foram substituídas por Exigir todos concedidos

RightHandedMonkey
fonte
Observe que os comandos Ordenar / Permitir / Negar ainda estão disponíveis na maioria dos computadores. Em versões mais recentes, é implementado no access_compatmódulo. Se esse módulo estiver ativado, a primeira parte provavelmente não funcionará conforme o esperado. Se não estiver lá, a tentativa de iniciar o Apache2 deve falhar com erros.
Alexis Wilke
Qual configuração? O /etc/httpd/conf/httpd.confnão existe no meu sistema e, também, o diretório /etc/httpd/não existe.
Aaron Franke
@AaronFranke Você tem o apache instalado? Pode estar aqui: /etc/apache2/httpd.conf /etc/apache2/apache2.conf
/etc/httpd/httpd.conf /etc/httpd/conf/httpd.conf
Sim, tenho o Apache instalado e estou no Ubuntu. /etc/apache2/apache2.confexiste para mim.
Aaron Franke
7

Relacionado a esta questão, acabei de descobrir por que meu vhost estava me dando aquele 403.

Eu testei TODAS as possibilidades nesta questão e em outras sem sorte. Quase me enlouquece.

Estou configurando um servidor com implantação de lançamentos semelhante ao Capistrano através de links simbólicos e quando tentei acessar a pasta DocRoot (que agora é um link simbólico para a pasta de lançamento atual) me deu o 403.

Meu vhost é:

DocumentRoot /var/www/site.com/html
<Directory /var/www/site.com/html>
        AllowOverride All
        Options +FollowSymLinks
        Require all granted
</Directory>

e meu arquivo httpd.conf principal era (instalação padrão do Apache 2.4):

DocumentRoot "/var/www"
<Directory "/var/www">
    Options -Indexes -FollowSymLinks -Includes
(...)

Acontece que a principal definição de Opções estava tendo precedência sobre meu fiel vhosts (para mim isso é contra intuitivo). Então eu mudei para:

DocumentRoot "/var/www"
<Directory "/var/www">
    Options -Indexes +FollowSymLinks -Includes
(...)

e Eureka! (observe o sinal de mais antes de FollowSymLinks no arquivo httpd.conf PRINCIPAL. Espero que isso ajude alguma outra alma perdida.

mustangp51d
fonte
No Apache 2.4, sua solução invalidará a configuração e o httpd falhará ao iniciar, pois você não pode combinar '+' e '-' em uma única linha de opções.
deesto de
Sim, era isso, embora eu tivesse declarado um DocumentRoot "anterior" no arquivo, ele estava substituindo a seção do diretório filho (o quê?)
rogerdpack
2

Há outra maneira de os links simbólicos falharem, como descobri em minha situação. Se você tiver um sistema SELinux como servidor e os links simbólicos apontam para uma pasta montada em NFS (outros sistemas de arquivos podem produzir sintomas semelhantes),httpd pode ver os contextos errados e se recusar a servir o conteúdo das pastas de destino.

No meu caso, o contexto SELinux de /var/www/html(que você pode obter com ls -Z) é unconfined_u:object_r:httpd_sys_content_t:s0. Os links simbólicos em/var/www/html terão o mesmo contexto, mas o contexto de seu destino, sendo uma pasta montada em NFS, sãosystem_u:object_r:nfs_t:s0 .

A solução é adicionar fscontext=unconfined_u:object_r:httpd_sys_content_t:s0às mountopções (por exemplo # mount -t nfs -o v3,fscontext=unconfined_u:object_r:httpd_sys_content_t:s0 <IP address>:/<server path> /<mount point>). rootcontexté irrelevante e defcontexté rejeitado pelo NFS. Eu não tentei contextpor conta própria.

Urhixidur
fonte
2

Primeiro desative o selinux (vim / etc / selinux / config)

vim /etc/httpd/conf/httpd.conf edite as seguintes linhas para links simbólicos e indexação de diretório:

documentroot /var/www/html
<directory /var/www/html>
    Options Indexes FollowSymLinks
    AllowOverride None
</directory>

Se o arquivo .htaccess, então AllowOverride todos

nsn srinivas
fonte
E se eu não tiver a /etc/httpd/pasta no meu sistema?
Aaron Franke
1

Além de alterar as permissões conforme as outras respostas indicaram, tive que reiniciar o apache para que ele tivesse efeito:

sudo service apache2 restart
tmath
fonte
0

Mais uma armadilha sutil, caso você precise AllowOverride All:

Em algum lugar no fundo da árvore de fs, um velho .htaccesstendo

    Options Indexes

ao invés de

    Options +Indexes

foi o suficiente para desabilitar indiferentemente o FollowSymLinksconjunto na configuração do servidor, e causar um misterioso 403 aqui.

Sz.
fonte