prática recomendada para permissão de acesso aos usuários do apache tomcat

Eu tenho uma caixa Linux sendo compartilhada por vários desenvolvedores. Eles querem implantar seus arquivos de guerra no apache tomcat, que em local compartilhado (/ opt / tomcat).

Como eles não têm acesso ao sudo, preciso alterar a permissão da pasta para o diretório tomcat.

estrutura de diretórios em /opt/tomcatis -

bin/

conf/

lib/

logs/

temp/

webapps/

work/

Quais são as melhores práticas na situação acima - permissão de acesso mais adequada ao usuário? Por enquanto, mudei a permissão para 777 para aplicativos e logs da web.

obrigado

Eu faço assim:

Colocamos o usuário do tomcat como proprietário da pasta do tomcat:

# chown -R tomcat:tomcat /opt/tomcat

Os usuários não podem modificar a configuração do tomcat:

# chmod -R g+r /opt/tomcat/conf

Os usuários podem modificar as outras pastas:

# chmod -R g+w /opt/tomcat/logs
# chmod -R g+w /opt/tomcat/temp
# chmod -R g+w /opt/tomcat/webapps
# chmod -R g+w /opt/tomcat/work

Ative o sticky-bit para novos arquivos, mantenha as permissões definidas:

# chmod -R g+s /opt/tomcat/conf
# chmod -R g+s /opt/tomcat/logs
# chmod -R g+s /opt/tomcat/temp
# chmod -R g+s /opt/tomcat/webapps
# chmod -R g+s /opt/tomcat/work

Por fim, adicionamos o grupo tomcat que queremos usuários que possam usar o tomcat:

# usermod -a -G tomcat MIUSER

A Non-Tomcat settingsseção do howto de segurança do Tomcat fornece informações úteis sobre este tópico. Veja aqui:

• Tomcat 7: https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html
• Tomcat 8: https://tomcat.apache.org/tomcat-8.0-doc/security-howto.html
• Tomcat 9: https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html

O Tomcat não deve ser executado no usuário root. Crie um usuário dedicado para o processo do Tomcat e forneça a esse usuário as permissões mínimas necessárias para o sistema operacional. Por exemplo, não deve ser possível fazer logon remotamente usando o usuário do Tomcat.

As permissões de arquivo também devem ser adequadamente restritas. Tomando como exemplo as instâncias do Tomcat no ASF (onde a implantação automática está desativada e os aplicativos da Web são implantados como diretórios explodidos), a configuração padrão é ter todos os arquivos do Tomcat pertencentes ao root com o grupo Tomcat e enquanto o proprietário tem privilégios de leitura / gravação , o grupo tem apenas leitura e o mundo não tem permissões. As exceções são os logs, temp e diretório de trabalho que pertencem ao usuário do Tomcat e não à raiz . Isso significa que, mesmo que um invasor comprometa o processo do Tomcat, ele não poderá alterar a configuração do Tomcat, implantar novos aplicativos da Web ou modificar aplicativos da Web existentes. O processo do Tomcat é executado com uma umask de 007 para manter essas permissões.

Você precisa seguir o princípio do menor privilégio . O servidor (provavelmente www-data, mas você precisará verificar) precisa poder ler a maioria dos arquivos (digamos todos) e gravar apenas nos logs. Os desenvolvedores da Web podem escrever onde precisam. Defina a parte adesiva nos diretórios para que somente o proprietário de um arquivo possa excluí-lo.

Na prática, você precisa criar um grupo (por exemplo webdev) e adicionar todos os desenvolvedores e o servidor a ele ( usermod -aG webdev <user>ou usermod -A webdev <user>dependendo do seu sabor Linux). chowntodos os arquivos e diretórios para o usuário do servidor da web, chmod todos os diretórios para 500 e todos os arquivos para 400 (exceto binonde os executáveis ​​também precisam ser 500).

Conceda permissões de gravação /opt/tomcatao grupo (que seria 570) e defina o bit adesivo para que eles possam remover apenas os arquivos que possuem (chmod 1570). Conceda ao servidor permissão de gravação nos logs e permissões de leitura para os desenvolvedores (0740 para a pasta, 0640 para os arquivos, o bit adesivo provavelmente não é necessário e nunca conceda a um arquivo, apenas as pastas, pois possui um significado diferente (execute com as permissões do proprietário quando o arquivo for executável)).

Você precisará conceder permissões de gravação (1570) para webdevalguns dos diretórios. Você precisará de algumas tentativas e erros aqui e pode ser dependente do aplicativo. Essas pastas devem ser 1570, enquanto outras podem ser 0500).

Os desenvolvedores precisarão conceder acesso de leitura em seus arquivos ao grupo para que o servidor possa lê-los (que é 640) e também execute nos diretórios (que são 750).

Acho que a resposta aceita da @ intropedro é boa. Vale ressaltar que o uso de um instalador de pacotes pode economizar muitas dores de cabeça - pelo menos para o Tomcat 7 no Ubuntu apt-get install tomcat7produz um conjunto de diretórios de instalação mais "padrão":

• /etc/tomcat7 para arquivos de configuração,
• /var/lib/tomcat7 para bibliotecas principais e
• /usr/share/tomcat7 para recursos compartilhados.

Todas as permissões são configuradas corretamente com o princípio do menor privilégio, de forma que adicionar usuários ao grupo tomcat7seja suficiente para permitir a implantação. Além disso, o servidor tomcat é configurado como um serviço que pode ser iniciado e parado como outros (por exemplo, sudo service tomcat startou alternativamente /etc/init.d/tomcat start). O Tomcat inicia na reinicialização automaticamente e há um comando "restart". Tenho certeza de que há um pacote yum equivalente para usuários do RHEL / CentOS. (E sim, há um instalador de homebrew para instalações locais do OSX).

Se você estiver tendo problemas, é /usr/share/binchamado um utilitário interessante configtest.shque informa se há permissões ou outros erros. Observe que há um erro aberto que sugere adicionar alguns links simbólicos .

Ainda estamos executando o Ubuntu trusty(14.04); para aqueles que executam versões mais recentes, acredito que exista um repositório Tomcat 8 apt-get.