web-dev-qa-db-pt.com

Por que não consigo excluir algo, mesmo que possua permissões 777 para teste?

Este aqui está me incomodando. Eu precisava reinstalar minha instalação do Joomla novamente . O que é bom, já que estou fazendo isso para praticar, em um esforço para aprender Joomla e Linux (CentOSv7).

Eu tive problemas anteriores com permissões de arquivo e propriedade que foram resolvidos com a leitura de logs de erros e testes com permissões 777 para verificar os usuários em execução. Problema é desta vez que não está funcionando?

Se todos tivessem permissão na pasta de imagens, por exemplo, eu esperaria poder excluir qualquer coisa sem problemas.

Aqui está o que recebo da página de administração quando tento criar uma pasta na raiz das imagens (com 777 permissões para teste)

JFolder::create: Could not create folder. Path: /srv/dpca/www/images/test

Estou em um host dedicado executando o Nginx com PHP v5.5. O Joomla não parece capaz de gravar logs e os erros levam a postagens sobre propriedade e permissões de arquivo. Isso faz sentido logicamente) mas acho que estou tendo um problema diferente.

Tento excluir uma imagem com 666 permissões atribuídas e ela falha e é bem-sucedida? Ainda não exclui embora.

Conflicting deletion message


Complemente as informações se isso ajudar a garantir minha posição Permissões do diretório raiz (note que estou testando 777 exclusivamente em imagens aqui):

drwxr-xr-x. 10 nginx nginx  4096 Dec 24 13:51 administrator
drwxr-xr-x.  2 nginx nginx    42 Dec 24 13:51 bin
drwxr-xr-x.  2 nginx nginx     6 Jan 12 20:48 cache
drwxr-xr-x.  2 nginx nginx  4096 Dec 24 13:51 cli
drwxr-xr-x. 16 nginx nginx  4096 Dec 24 13:51 components
-r--r-----.  1 nginx nginx  1885 Jan 12 20:07 configuration.php
-rw-r--r--.  1 nginx nginx  2915 Dec 24 13:51 htaccess.txt
drwxrwxrwx.  5 nginx nginx  4096 Jan 11 21:04 images
drwxr-xr-x.  2 nginx nginx    61 Dec 24 13:51 includes
-rw-r--r--.  1 nginx nginx   140 Jan 10 22:03 index.html
-rw-r--r--.  1 nginx nginx  1212 Dec 24 13:51 index.php
-rw-r--r--.  1 nginx nginx  1873 Dec 24 13:53 joomla.xml
drwxr-xr-x.  2 nginx nginx     6 Jan 10 22:09 jrt
drwxr-xr-x.  4 nginx nginx    51 Dec 24 13:51 language
drwxr-xr-x.  5 nginx nginx    66 Dec 24 13:51 layouts
drwxr-xr-x. 11 nginx nginx  4096 Dec 24 13:51 libraries
-rw-r--r--.  1 nginx nginx 18092 Dec 24 13:51 LICENSE.txt
drwxr-xr-x.  2 nginx nginx    23 Dec 24 13:51 logs
drwxr-xr-x. 18 nginx nginx  4096 Dec 24 13:51 media
drwxr-xr-x. 27 nginx nginx  4096 Dec 24 13:51 modules
drwxr-xr-x. 14 nginx nginx  4096 Dec 24 13:51 plugins
-rw-r--r--.  1 nginx nginx  4213 Dec 24 13:51 README.txt
-rw-r--r--.  1 nginx nginx   842 Dec 24 13:51 robots.txt.dist
drwxr-xr-x.  5 nginx nginx    64 Dec 24 13:51 templates
drwxr-xr-x.  2 nginx nginx     6 Jan 12 20:52 tmp
-rw-r--r--.  1 nginx nginx  1690 Dec 24 13:51 web.config.txt

Mostrando que o php-fpm e o servidor da web estão sendo executados com o usuário correto:

nginx     64106  0.0  1.1 412288 20668 ?        S    Jan10   0:06 php-fpm: pool www
nginx     64107  0.0  1.0 412108 20260 ?        S    Jan10   0:06 php-fpm: pool www
nginx     64108  0.0  1.2 415252 23608 ?        S    Jan10   0:06 php-fpm: pool www
nginx     64109  0.0  1.2 414472 22780 ?        S    Jan10   0:05 php-fpm: pool www
nginx     64110  0.0  1.1 413048 21340 ?        S    Jan10   0:06 php-fpm: pool www
nginx     64250  0.0  1.0 411880 20276 ?        S    Jan10   0:06 php-fpm: pool www
nginx     99912  0.0  1.1 413276 21320 ?        S    08:13   0:01 php-fpm: pool www
root     117112  0.0  0.0  47548  1184 ?        Ss   20:49   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    117113  0.0  0.1  50144  2520 ?        S    20:49   0:00 nginx: worker process
1
Matt

O SELinux era meu problema. Consegui gravar nos diretórios depois de configurá-lo para o modo permissivo.

Sudo setenforce 0

No entanto, eu não queria desabilitá-lo totalmente, conforme definido para corrigir o problema. Seguindo as etapas de CentOS no SELinux Consegui determinar o contexto correto para as pastas/arquivos que deveriam ser graváveis. Enquanto estava no modo permissivo, adicionei uma imagem na página Administrador.

Por padrão, as mensagens de log do SELinux são gravadas em /var/log/audit/audit.log através do Linux Auditing System auditd, que é iniciado por padrão.

O log é um pouco enigmático, portanto, você pode executar algo assim que fornecerá uma resposta mais interpretativa e até a ação recomendada.

SELinux is preventing /usr/sbin/php-fpm from write access on the directory /srv/dpca/www/images.

*****  Plugin httpd_write_content (92.2 confidence) suggests   ***************

If you want to allow php-fpm to have write access on the images directory
Then you need to change the label on '/srv/dpca/www/images'
Do
# semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/images'
# restorecon -v '/srv/dpca/www/images'

Naquele momento, esse era o contexto das imagens (e de todas as outras pastas)

drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 images

Então, escrevi um pequeno script que lia todas as pastas que deveriam ser gravadas conforme Informações do sistema> Permissões de pasta (com exceção do configuration.php). Não é um bom exemplo de programação, mas foi basicamente a repetição dos seguintes comandos sendo executados.

Sudo semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/{folder}'
Sudo restorecon -v '/srv/dpca/www/{folder}'

onde a pasta foi substituída para cada passe. Após o que eu configurei o SELinux de volta ao modo de imposição com Sudo setenforce 1.

Depois de verificar Informações do sistema> Permissões de pasta novamente, agora vejo minhas pastas como graváveis.

2
Matt

A maneira mais rápida de verificar se a sua instalação do Joomla! Tem a permissão necessária, é a função integrada:

Vá para Sistema-> Informações do sistema-> Permissões de pasta, que devem ser algo como isto: enter image description here Lá você pode ver exatamente se há algum problema com suas permissões ou outra coisa.

3
dennlinger