H00035: acesso a “file.php” negado, como configurar corretamente o SELinux?

0

Eu tenho lutado nos últimos dias com esse problema e até agora não consegui encontrar nenhuma solução. A questão em poucas palavras é (mensagem de erro):

H00035: access to index.php denied because search permissions are missing on a component of the path

Onde esta aplicação está em execução?

  • o host é o Windows 10
  • esta é uma VM rodando dentro do VirtualBox e gerenciada pelo Vagrant
  • CentOS Linux release 7.5.1804 (Core)
  • Apache / 2.4.33 (IUS)
  • PHP 7.2.6 (não que isso importe, mas apenas no caso)
  • SELinux: impondo

O que tentei até agora:

  • Ran os seguintes comandos na caixa: funcionou? NÃO (encontrado aqui )

    find /var/www -type d -exec chmod 755 {} \;
    find /var/www -type f -exec chmod 664 {} \;
    
  • Ran os seguintes comandos na caixa: funcionou? NÃO (encontrado aqui )

    chcon -R -t httpd_sys_content_t /var/www
    

Tentei tudo em aqui , Funcionou? NÃO .

O que eu tentei e trabalhei? Desativar o SELinux !!! Então, com certeza, é uma configuração do SELinux.

As permissões em /var/www parecem as seguintes:

# namei -mo /var/www/api/public/index.php
f: /var/www/api/public/index.php
 dr-xr-xr-x root    root    /
 drwxr-xr-x root    root    var
 drwxrwxr-x vagrant vagrant www
 drwxrwxr-x vagrant vagrant api
 drwxrwxr-x vagrant vagrant public
 -rwxrwxr-- vagrant vagrant index.php

O que mais posso tentar aqui para resolver o problema? Eu sei que o caminho fácil seria "desabilitar o SELinux", mas eu não quero fazer isso, seria melhor aprender como fazer as coisas certas:)

Esta caixa foi criada usando Puphpet e posso compartilhá-la. Deixe-me saber se você precisa para testes.

UPDATE # 1:

@ A resposta de hbruijn me deu a idéia de mudar o proprietário de vagrant para Apache www-data e o H00035 acabou, mas eu ganhei um novo.

// Before
synced_folder:
    folder1:
        owner: vagrant
        group: vagrant
        source: ../../www/html
        target: /var/www
        sync_type: default

// After
synced_folder:
    folder1:
        owner: www-data
        group: www-data
        source: ../../www/html
        target: /var/www
        sync_type: default

O erro como está agora:

(13)Permission denied: [client 192.168.50.1:2048] AH00529: /var/www/api/public/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/www/api/public/' is executable

Esta é a saída da resposta do @ hbruijn:

# ls -lZ /var/www/
drwxrwxr-x. www-data www-data system_u:object_r:vmblock_t:s0   api/
-rwxrwxr--. www-data www-data system_u:object_r:vmblock_t:s0   index.html*

Eu executei o mesmo comando novamente: find /var/www -type f -exec chmod 664 {} \; , mas isso não alterou nada, o que significa que as permissões permanecem as mesmas de antes.

Alguma idéia?

    
por ReynierPM 14.06.2018 / 14:56

2 respostas

1

O problema provavelmente está enraizado no fato de você expor parte do sistema de arquivos do host como dados / var / www em sua VM do VirtualBox.

Obviamente, o Windows não possui os atributos de arquivo necessários para fornecer contextos SELinux.

Assim, sua VM usa um contexto de segurança padrão.

O contexto de segurança padrão para um sistema de arquivos "desconhecido" não é um contexto que se alinhe bem com a execução de um servidor da Web.
Verifique com ls -lZ /var/www/ . Seu servidor precisa de algo como

drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html 

e atualmente você provavelmente está fazendo algo diferente como:

drwxrwxrwx. vagrant vagrant system_u:object_r:vmblock_t:s0 /var/www/api

Você pode tentar forçar manualmente o contexto correto do SELinux como uma opção de montagem:

mount -o remount,context="system_u:object_r:httpd_sys_content_t:s0" /var/www

e se isso funcionar como pretendido (verifique com ls -Z ) você provavelmente pode adicionar isso às opções de montagem em / etc / fstab ou no seu arquivo vagrant

    
por 14.06.2018 / 15:41
0

restorecon -vRF /var/www irá restaurar o contexto de segurança padrão para todos os arquivos abaixo de / var / www. Se você não alterou as políticas do selinux, isso deve resolvê-lo. Como uma observação, se você mover os arquivos em outro lugar, poderá alterar esses contextos fazendo:

semanage fcontext -a -e /var/www /somewhere/www
restorecon -vRF /somewhere/www

No seu caso, não deve ser necessário porque o / var / www já tem rótulos padrão definidos (por exemplo, contextos), mas um diretório diferente não, então você tem que mudá-los e depois aplicá-los. Você pode ter uma ideia do nome do caminho para os mapeamentos de contexto com grep www /etc/selinux/targeted/contexts/files/file_contexts ,

Além disso, o chmod afeta apenas os controles discricionários (permissões de arquivo), não os controles obrigatórios (políticas) do selinux. Ambos precisam estar certos para que funcione, mas se você desativou o selinux e funcionou, não é necessário fazer isso novamente.

Além disso, / var / log / messages deve registrar todos os erros do selinux e informar o objeto que está bloqueando o acesso. Se você fizer um temporário 'setenforce 0' que irá alterar o selinux para o modo permissivo de modo que todas as ações funcionem, mas você ainda receberá os erros de log que você pode consertar todos antes de ligá-lo novamente. Se isso falhar, veja a instalação dos pacotes setroubleshoot e setroubleshoot-server, que lhe darão ainda mais informações.

    
por 04.07.2018 / 07:27