best practice per il permesso di accesso agli utenti per apache tomcat

Ho una scatola Linux condivisa da vari sviluppatori. Vogliono distribuire i loro file di guerra in apache tomcat che in posizione condivisa (/ opt / tomcat).

Dato che non hanno accesso sudo, devo cambiare i permessi della cartella per la directory tomcat.

la struttura di directory sotto /opt/tomcatè -

bin/

conf/

lib/

logs/

temp/

webapps/

work/

Quali sono le migliori pratiche nella situazione precedente: l'autorizzazione di accesso più adatta all'utente? Per ora, ho cambiato l'autorizzazione a 777 per webapp e log.

Grazie

Lo faccio in questo modo:

Mettiamo l'utente tomcat come proprietario della cartella di tomcat:

# chown -R tomcat:tomcat /opt/tomcat

Gli utenti non possono modificare la configurazione di tomcat:

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

Gli utenti possono modificare le altre cartelle:

# 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

Attiva il sticky-bit per i nuovi file mantenendo le autorizzazioni definite:

# 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

Infine, aggiungiamo il gruppo tomcat che desideriamo agli utenti che possano utilizzare il tomcat:

# usermod -a -G tomcat MIUSER

La Non-Tomcat settingssezione del howto sulla sicurezza di Tomcat fornisce informazioni utili su questo argomento. Vedere qui:

• 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

Tomcat non deve essere eseguito con l'utente root. Crea un utente dedicato per il processo Tomcat e fornisci all'utente le autorizzazioni minime necessarie per il sistema operativo. Ad esempio, non dovrebbe essere possibile accedere in remoto utilizzando l'utente Tomcat.

Anche le autorizzazioni per i file dovrebbero essere opportunamente limitate. Prendendo come esempio le istanze Tomcat nell'ASF (in cui la distribuzione automatica è disabilitata e le applicazioni Web sono distribuite come directory esplose), la configurazione standard prevede che tutti i file Tomcat siano di proprietà di root con il gruppo Tomcat e mentre il proprietario ha i privilegi di lettura / scrittura , il gruppo ha solo letto e il mondo non ha autorizzazioni. Le eccezioni sono i registri, la temp e la directory di lavoro di proprietà dell'utente Tomcat anziché di root . Ciò significa che anche se un utente malintenzionato compromette il processo Tomcat, non può modificare la configurazione Tomcat, distribuire nuove applicazioni Web o modificare le applicazioni Web esistenti. Il processo Tomcat viene eseguito con un umask di 007 per mantenere queste autorizzazioni.

Devi seguire il principio del privilegio minimo . Il server (probabilmente www-data, ma dovrai verificarlo) deve essere in grado di leggere la maggior parte dei file (diciamo tutti) e scrivere solo nei log. Gli sviluppatori web sono autorizzati a scrivere dove servono. Imposta il bit appiccicoso sulle directory in modo che solo il proprietario di un file possa eliminarlo.

In pratica, devi creare un gruppo (ad esempio webdev) e aggiungere tutti gli sviluppatori e il server ( usermod -aG webdev <user>o in usermod -A webdev <user>base al tuo stile di Linux). chowntutti i file e le directory per l'utente del server web, chmod tutte le directory su 500 e tutti i file su 400 (eccetto bindove anche gli eseguibili devono essere 500).

Concedere le autorizzazioni di scrittura /opt/tomcatal gruppo (che sarebbe 570) e impostare il bit sticky in modo che possano rimuovere solo i file di loro proprietà (chmod 1570). Concedere al server l'autorizzazione di scrittura per i registri e le autorizzazioni di lettura per gli sviluppatori (0740 per la cartella, 0640 per i file, probabilmente il bit appiccicoso non è necessario e non concederlo mai a un file, solo alle cartelle, poiché ha un significato diverso (eseguire con le autorizzazioni del proprietario quando il file è eseguibile)).

Quindi dovrai concedere le autorizzazioni di scrittura (1570) ad webdevalcune directory. Avrai bisogno di prove ed errori qui e potrebbe dipendere dall'applicazione. Tali cartelle devono essere 1570, mentre altre possono essere 0500).

Gli sviluppatori dovranno concedere l'accesso in lettura ai propri file al gruppo in modo che il server possa leggerli (ovvero 640), ed eseguire anche sulle directory (750).

Penso che la risposta accettata da @ intropedro sia buona. Vale la pena sottolineare che l'uso di un programma di installazione di pacchetti può risparmiare molti mal di testa - almeno per Tomcat 7 su Ubuntu apt-get install tomcat7produce un set più "standard" di directory di installazione:

• /etc/tomcat7 per i file di configurazione,
• /var/lib/tomcat7 per le librerie core e
• /usr/share/tomcat7 per risorse condivise.

Tutte le autorizzazioni sono impostate correttamente con il principio del privilegio minimo, in modo tale che l'aggiunta di utenti al gruppo tomcat7sia sufficiente per consentire la distribuzione. Inoltre, il server Tomcat è impostato come servizio che può essere avviato e arrestato come altri (ad esempio sudo service tomcat starto in alternativa /etc/init.d/tomcat start). Tomcat si avvia automaticamente al riavvio e c'è un comando "riavvia". Sono sicuro che esiste un pacchetto yum equivalente per gli utenti RHEL / CentOS. (E sì, c'è un programma di installazione homebrew per le installazioni OSX locali).

Se hai problemi, c'è una bella utility /usr/share/binchiamata configtest.shche segnala se ci sono permessi o altri errori. Nota, c'è un bug aperto che suggerisce l'aggiunta di alcuni collegamenti simbolici .

Stiamo ancora eseguendo Ubuntu trusty(14.04); per quelli che eseguono versioni più recenti credo che ci sia un repository apt-get Tomcat 8.