Problema de Permissões do Usuário no CentOS 7: “Permissão negada”

Question

Eu achei que sabia como configurar permissões no Linux. Eu aparentemente não sei.

Eu tenho um usuário chamado "web3". Este usuário foi criado automaticamente pelo ISPConfig (um aplicativo de gerenciamento de servidor como o CPannel).

Eu também tenho um aplicativo que eu instalei no servidor chamado "Drush". Eu instalei o "Drush" enquanto estava logado como root. Esta aplicação está localizada em:

/root/.composer/vendor/drush/drush/drush

Este arquivo e sua pasta contendo as seguintes permissões:

-rwxr-xr-x 1 root root
drwxr-xr-x 9 root root

Como o arquivo permite a leitura e a execução de permissões para todos, como sempre que faço login como usuário "web3" e tento executar o aplicativo mencionado, recebo a seguinte mensagem de erro:

/root/.composer/vendor/drush/drush/drush: Permission denied

Já enfrentei esse problema antes, mas recorri a dar permissões de root completas ao usuário com o qual estava tendo problemas. Em um ambiente de desenvolvimento local, isso não é grande coisa. Estou gerenciando meu próprio servidor dedicado agora e essa solução não funcionará.

O que estou fazendo de errado?

Eu gostaria de receber ajuda!

    

Answer 1

/root/ é o diretório inicial do root. As permissões em /root/ são esperadas 700, impedindo que qualquer pessoa, exceto root, percorra toda a árvore de diretórios abaixo dela.

Você está sendo impedido de executar o binário como um usuário não root por meio de permissões na árvore de diretórios.

A instalação de qualquer coisa em /root/ é incomum, você normalmente instalaria um código executável para ser usado por vários usuários em /opt/ ou outro diretório.

Então essas são as duas principais coisas que estão "erradas". Você precisa encontrar um local melhor para instalar o código e garantir que o caminho completo seja acessível aos usuários que deseja usá-lo.

Por último, como outros apontam, enquanto você precisa ser root para concluir uma instalação, os arquivos resultantes devem ser de propriedade do root, se necessário. Em muitos casos, usuários específicos são criados (como o usuário www-data ou um usuário oracle), o que limita a exposição se o código for comprometido. Não conheço seu aplicativo, mas pode valer a pena instalá-lo como o usuário web3 ou instalá-lo como root, mas alterar as permissões posteriormente para um usuário não privilegiado criado especificamente para a tarefa.

Você deve resistir ao desejo de abrir as permissões em /root/ para corrigir o problema, e sudo é um esparadrapo sobre o problema. O problema é que você não deve instalar o código executável no diretório pessoal do root.

    

Answer 2

Apenas verificar as permissões da pasta contida não será suficiente: você precisará verificar as permissões de todas as pastas de nível superior, até o diretório raiz. Por exemplo, assim:

# ls -ld /root/.composer/vendor/drush/drush/drush \
  /root/.composer/vendor/drush/drush \
  /root/.composer/vendor/drush \
  /root/.composer/vendor \
  /root/.composer \
  /root \
  /

Você pode descobrir que o diretório /root tem permissões 700 (ou drwx------ ) e que está impedindo que o usuário web3 prossiga mais nesse caminho. Não é uma boa idéia permitir que outros usuários acessem o diretório home do usuário root , embora tecnicamente você possa conceder permissões 711 ( drwx--x--x ) se considerar absolutamente necessário.

Mas é possível que isso não o ajude ...

Você está usando o CentOS 7, que tem o SELinux habilitado por padrão.

O RHEL / CentOS tem uma configuração padrão do SELinux que normalmente tem um efeito muito insignificante nas contas de usuários comuns, mas pode colocar alguns limites estritos nos serviços do sistema - como um servidor web, por exemplo.

No SELinux, é possível restringir um processo e todos os seus descendentes de certas ações - independentemente do sistema tradicional de usuário / grupo / permissões do estilo Unix. Essas restrições podem ser configuradas para "travar" automaticamente quando certos binários são executados, para determinados usuários do sistema e em uma infinidade de outras condições.

Uma das restrições padrão do SELinux para um servidor web é que o acesso a qualquer coisa fora dos diretórios especificamente habilitados como /var/www é bloqueado, a menos que seja habilitado especificamente usando um SELinux booleano , um tipo de opção selecionável no SELinux. conjunto de regras. Acho que isso pode ser outra coisa impedindo o usuário web3 de acessar o aplicativo Drush.

Se você quiser que um servidor da Web (ou qualquer um de seus descendentes, como um interpretador PHP) acesse qualquer conteúdo que não esteja em /var/www e seja criado por outros usuários, será necessário executar este comando:

# setsebool -P httpd_read_user_content 1

No RHEL / CentOS, cada serviço do sistema possui uma página man adicional, denominada <service name>_selinux , que contém informações sobre restrições do SELinux e booleanos para esse serviço específico. Essas páginas man vêm em um pacote RPM denominado selinux-policy-doc : aqui tem mais informações sobre esse pacote. Se você estiver usando um sistema com o SELinux ativado, você realmente deve ler essas páginas de manual para todos os serviços que você está planejando executar: eles lidam com o SELinux apenas so muito mais fácil.

Claro, você pode encontrar na internet muitas sugestões sobre como desabilitar o SELinux, mas se você estiver planejando executar um servidor seguro, essa pode não ser a melhor opção.