Remova o chroot imediatamente

As informações em sua pergunta anterior incluíam uma referência a /usr/share/cagefs-skeleton.

Isso sugere que o problema com o qual você está tendo problemas pode não ser apenas um chroot normal, mas um chroot cagefs, que é um recurso do CloudLinux e aparentemente está vinculado a vários painéis de controle de hospedagem, como cPanel, Plesk e outros.

Parece que você não deseja tanto remover o chrootcomando (que faz parte do coreutilspacote, a propósito), mas sim remover a configuração do chroot que está restringindo seus scripts web PHP. Nesse caso, parece-me que, nesse caso, o CloudLinux pode ser uma escolha errada de distribuição para o tipo de aplicativo que você está tentando fazer.

A "maneira da nuvem" de atualizar seu sistema operacional seria:

1. vá para o painel de administração da sua hospedagem
2. crie uma nova VM com a versão do sistema operacional de sua escolha a partir de modelos oferecidos pelo seu hoster
3. reimplante seu aplicativo nele usando a automação de sua escolha
4. destruir a versão antiga da VM na nuvem

O CloudLinux parece ser adaptado especificamente para esse tipo de paradigma operacional. Não sei exatamente como você deseja trabalhar com seu aplicativo, mas pelas suas perguntas, parece-me que o "jeito da nuvem" não é realmente esse.

Eliminar cagefso CloudLinux provavelmente funcionaria mais do que reimplantar seu aplicativo em uma distribuição diferente que seja mais adequada à maneira como você deseja operar.

$ type chroot
chroot is /usr/sbin/chroot
$ rpm -qf /usr/sbin/chroot
coreutils-8.30-15.el8.x86_64

Acho altamente improvável que o coreutils não esteja instalado no seu sistema. E você realmente não quer remover coreutils de nenhum sistema GNU/Linux.

O rpm -qacomando lista os pacotes, não o seu conteúdo. Nem todo arquivo possui seu próprio pacote e a maioria dos pacotes contém muitos arquivos.

A existência de um binário tem pouco a ver com processos no sistema. O pscomando não cria um índice e é quase certo que você nunca verá o chroot em execução e ele não iniciará sozinho.

Remover serviços não utilizados é uma boa ideia, mas remover coisas que você não entende, serviços ou binários, não é uma boa ideia.

Não faz sentido remover o chroot, isso não tornará seu sistema mais seguro.

A resposta correta raramente é a resposta popular, embora talvez isso possa ter um efeito positivo para aqueles capazes de "consegui-la" e que não são vulneráveis ​​a depender completamente da técnica preguiçosa de prova social, observando a pontuação da resposta. O problema chrooté que ele não foi desenvolvido adequadamente . Qualquer funcionalidade deve ter suporte para cinco funções principais:

• Índice: exibindo uma lista de todas as instâncias.
• Criar: se você não pode criar algo, não pode usá-lo.
• Editar: se você não pode modificá-lo, isso torna o processo de criação inutilmente complicado.
• Pesquisa: se você não consegue encontrar uma ou várias instâncias quando pode haver centenas, isso é muito complicado.
• Excluir: se você não consegue remover algo, isso cria mais problemas.

O chrootcomando suporta apenas a funcionalidade de criação - não suporta mais nada! Aparentemente, isso remonta ao final da década de 1990?! Então, literalmente, milhares de outros desenvolvedores poderiam ter corrigido essa função nas últimas duas décadas e mudado - e não o fizeram . Não - não conheço nenhuma função semelhante, destruir meia semana do meu tempo é extremamente irresponsável para quem decidiu que era uma ideia boa ou desejável usar esta função que ainda não está pela metade!

Eu compreendo perfeitamente a noção de por que ele foi criado, mas o problema é a falta da funcionalidade de edição, se pelo menos ela tivesse sido construída e deveria ter estendido a chrootprisão para incluir arquivos no sistema de arquivos normal - não cópias! Como desenvolvedor, é minha responsabilidade acompanhar quando as coisas precisam ser atualizadas . Se algo que estou referenciando é uma cópia, então os dados que estou referenciando estão errados! A funcionalidade estendida adequadamente também incluiria permissões: leitura, gravação e execução e eu só preciso ler esses arquivos. Quantos desenvolvedores poderiam produzir essa funcionalidade em alguns dias, se é que isso?!

Então, quando eu puder pagar um desenvolvedor Linux adequadamente, farei com que eles criem uma função real e adequada que seja facilmente muito superior. Uma boa ideia só é efetivamente boa se a execução também for boa!

Quebrando o Chroot Jail (sem precisar removê-lo completamente)

1. Efetuei login no rootusuário Linux usando PuTTY/SSH.
2. Usei o comando find / -name '*chroot*'para encontrar instâncias no sistema de arquivos.
3. Limpei instâncias redundantes/inúteis excessivas no Notepad++.
4. Notei muitas ocorrências em nomes de diretórios para cagefs.
5. Acabei acessando o WHM e descobri que havia um plugin para o CageFS.
6. Eu vi o usuário Linux que o PHP usa ( shell_exec('whoami')) e os removi.
7. Depois que o commit foi desconectado do meu próprio sistema (bom sinal).
8. Entrei no meu próprio painel de controle e vi que os shell_exec()comandos relevantes agora estavam funcionando.

Infelizmente não conheço a sintaxe do problema, então, para alguém que não tem uma configuração semelhante, peço desculpas, pois está claro que a maioria das pessoas lutará contra você. Em geral, a chrootprisão é uma boa ideia, embora seja executada da pior maneira possível e, ao mesmo tempo, seja aceita cegamente. Se você não está rastreando algo importante, como versões de software por meio de variáveis ​​de servidor para manter o software atualizado, então não, provavelmente não há razão para quebrar a chrootprisão, mas você não pode ser livre a menos que também seja responsável.