☰

A propriedade do arquivo do diretório wordpress muda sempre após o upload de arquivos/plugins

tag-icon • tag-icon linux apache-2.2 permissions wordpress
A propriedade do arquivo do diretório wordpress muda sempre após o upload de arquivos/plugins

no centos 7, criei um site wordpress com propriedade de diretório raiznome do site: grupo de sitese permissões de diretório755, permissões de arquivo644definido por padrão

quando o desenvolvedor faz login no painel do wordpress e tenta fazer upload de algo para a mídia ou instalar plug-ins, o wp diz que não há permissão de gravação,

então eu tive que dar permissões g + w para o diretório raiz do wp, então ele pôde instalar o plugin ou fazer upload de mídia.

depois de enviar a mídia, a permissão do plugin/mídia enviada muda paraapache:apachedenome do site: grupo de sites

como evitar?

  1. Eu dando permissões g + x ao diretório raiz wp para permitir que o desenvolvedor instale plug-ins/upload de mídia
  2. e a propriedade de qualquer upload do wp dashboar não deve ser alterada para apache:apache

o que eu tentei

Atualmente não encontrei nenhuma alternativa para impedir isso, sempre que tive que dar permissões g + w e revertê-las após o trabalho do desenvolvedor

Responder1

O servidor web (ou o processo PHP, dependendo da sua configuração) precisa de acesso de gravação ao diretório. A única maneira viável é executar esse processo como usuário websitename.

Principalmente outra opção seria conceder ao usuário apachepermissões de gravação via ACL ou adicioná-lo ao websitegroupgrupo, mas isso também resultaria na propriedade dos arquivos enviados por apache. Se você deseja que todos os arquivos e pastas sejam de propriedade de websitenamevocê, você precisa executar o servidor da web como esse usuário.

Responder2

Sua descrição de como isso é provisionado não é útil. Vamos começar do zero.

Usuários:

  • apache - o uid que seu tempo de execução do PHP executa como
  • dev1, dev2, dev2 - desenvolvedores
  • backup - para criar backups do site
  • support[n] - para investigar problemas

Devido à forma como o Wordpress foi projetado, é muito difícil operar, a menos que o "apache" tenha acesso total de leitura/gravação ao site.

Se todo o gerenciamento for feito através da interface web, os desenvolvedores precisamqualqueracesso aos arquivos na raiz do documento. No entanto, tenho visto sites onde os desenvolvedores usam rotineiramente o acesso CLI para arquivos atualizados. Então, vamos supor que eles precisem de acesso de leitura/gravação.

Os uids de backup precisam de acesso somente leitura aos arquivos.

O suporte precisa de acesso somente leitura aos arquivos.

Isso só deixa o usuário do site. Esta é a sua construção. Na ausência de informações adicionais sobre como você está usando isso, parece totalmente redundante.

Portanto, as únicas classes de acesso são leitura+gravação e somente leitura. Mas só por diversão, diremos que existe uma classe adicional sem acesso - e chamaremos esse usuário de "alienígena".

A propriedade do usuário é sempre determinada pelo uid que cria um arquivo - e tem valor único por usuário. Portanto, não podemos usar isso como mecanismo para permitir acesso.

No entanto, os usuários podem pertencer a vários grupos e cada grupo pode ter vários usuários. Assim podemos associar o privilégio de leitura e gravação a um grupo específico. Chame isso de atualização da web.

Isso deixa o acesso somente leitura (backup e suporte) - que pode ser fornecido por meio dos "outros" bits de permissão.

Mas como então excluir “alienígena”? Ao colocar o site em um diretório ao qual o estrangeiro não tem acesso - isso significa que precisamos de outro grupo que identifique as pessoas que têmalgunsacesso. Chame isso de acesso web.

Portanto, a associação ao grupo:

  • atualização da web: apache, dev1, dev2...devn
  • acesso web: apache, dev1, dev2...devn, backup, suporte[n]

então temos os diretórios, permissões e propriedade:

drwxr-x--- root:webaccess /var/www/SITENAME
drwxrwxr-x ????:webupdate /var/www/SITENAME/html  (document root)

Tudo muito bem, mas quando alguém em "webupdate" cria um novo arquivo ou diretório na raiz do documento, a propriedade do grupo será o grupo PADRÃO - não o webupdate. Você pode alterar esse comportamento com o bit setgid nos diretórios:

drwxrwSr-x ????:webupdate /var/www/SITENAME/html

A última parte do quebra-cabeça é garantir que o umask esteja definido como 00x para membros do webupdate para que novos arquivos e diretórios adquiram as permissões corretas). Não se esqueça de definir isso em seu sshd_config para o servidor sftp, bem como para shells interativos.

Portanto, depois de definir os grupos, você pode executar:

chown -R apache:webupdate  /var/www/SITENAME/html
chmod -r g+s /var/www/SITENAME/html

E é isso - você nunca mais precisará corrigir as permissões.

informação relacionada